Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Suitably dynamic versioning (graspologic-org#467)
* Suitably dynamic versioning The following versioning code bypasses a few problems with python module versions. The following scenarios are plausible: - A user clones `graspologic` and runs `pip install -r requirements.txt` then executes `python` in the project directory, accessing the graspologic library by python's local folder structure. - A users clones `graspologic` and runs `python setup.py install` in the environment of their choice, accessing the graspologic library either by the local folder structure or the .egg in their site-packages, depending on their current working directory. - A user clones no repository and wants to install the library solely via `pip` via the `pip install ...` command, which has 2 wings to consider: - The user wishes to try out the latest prerelease, which is going to be published with a X.Y.ZdevYYYYMMDDBUILDNUMBER style version and can be installed via `pip install graspologic --pre` - The user wishes to try out the latest release, which will be published as `X.Y.Z`. This PR supports those 4 cases (notably, it does not support `pip install .` from the root project directory, which does some super weird stuff and I gave up on trying to solve it a long time ago) The concept is this: the actual version upon a **build action**, which can be undertaken by: - CI building a snapshot build - CI building a release build - Local user building a local build These states all require the same thing: a materialized version in a file. This version should be created at the time of this build action. In the case of CI, we can populate the file in our CI build process and move on. It's the case of not being in CI where we need to consider what to do next, which leaves Local user building a local build (and local user using the filesystem as the library). In these cases, the solution is the following: if we have a populated version.txt file, we use it. If we do not, we materialize a new version based on the `__semver` in version.py and the current time in YYYYMMDDHHmmSS format. This means that if you are running on the filesystem, and you say `import graspy; print(graspy.__version__);`, it will actually tell you the version is `0.1.0dev20200926120000` as an example. However, when you close the interpreter and do it again, it will tell you that the version is `0.1.0dev20200926120500` - because it will create a version for you at the time of import. However, if you were to run `python setup.py install`, the setup.py file actually takes it on itself to either get a version number or use the materialized version described above, then to write it to version.txt. Which means that installing the graspologic library from setuptools will actually lock in the version number in perpetuity. Gotchas - version.txt must always be empty in the source tree - `pip install .` does some weird thing where it registers an entry in site-packages that is like a symlink to the local filesystem anyway so it doesn't actually make an egg which means you get a new version each time and I gave up caring at this point since we got the three primary use cases: developers, users of pre-releases, and users of releases all covered. Users who install by cloning and running pip install are just going to get a weird behavior that probably isn't that important to track down, and regardless they'll get a clear `X.Y.Zdev<timestamp>` in their `graspologic.__version__` which is enough for us to go on if there are any issues raised. * My testing resulted in filling this file and committing it, like I said not to do * Updated conf.py for sphinx to be able to find a version it likes. Or kinda likes. Maybe likes? * Forgot I had to add the recursive-include for the version file. * Making black happy
- Loading branch information