I'm working with a software that has an embedded python environment which does not have all of the standard python modules available.
For example there's no pip or pkg_resources. The only way to add 3rd-party modules/packages is by copying them into a path which is referenced in sys.path.
At the moment I am writing the first version of my own package and more will come in the future.
Now to my question. Is it considered a bad approach to have the version number inside the package name or completely as subpackage?
For example mypackage_0_1/ or mypackage/0_1/
If so, what would be a good alternative to solve this problem?
In most of the cases, the version number in a package, regardless of the language, is used to communicate compatibility. For example, Qt: there are Qt4 and Qt5 series. What the numbers mean is that we have different APIs and switching from Qt4 to Qt5 will mostly break your application. Likewise, Python follows this pattern: you have Python 2.x and 3.x series. This means that if you write your application for Python 3.6, it is expected that it will work with Python 3.7. In other words, Python 3.x releases are forward compatible (ie, software written for a older version of Python 3.x is expected to run OK with newer versions). However, writing your application for Python 2.7 and running it in Python 3.7, for example, will mostly bring unexpected results. Hence, Python 3.x breaks the compatibility with Python 2.x and they are neither forward of backward compatible.
So, my advice is to follow this rule: use a version number in the package name only and only if you are communicating that you are creating a series of forward compatible versions of your package.