Implement a mechanism for automatically generating pip installers
We need to ensure that any PyPI version can be cross-referenced to a specific point in the VCS history. In that regard, it is worth investigating how the generation of the pip installer for publication on PyPI can be automated. This will also serve to minimise the risk of e.g. a developer publishing a "wrong" installer bundle on PyPI.
In particular it would be useful to:
- include a commit hash
The PEP440 standard (versioning) makes provision for including commit hashes in the project metadata (but not in the actual version identifier). And esp. the section on "local version labels" is interesting:
The inclusion of the local version label makes it possible to differentiate upstream releases from potentially altered rebuilds by downstream integrators. The use of a local version identifier does not affect the kind of a release but, when applied to a source distribution, does indicate that it may not contain the exact same code as the corresponding upstream release.
We need to:
investigate how this affects the
pip install niftynetcommand if such a "local version" is published on PyPI
Creating a pip installer
- Set the
versionparameter of the
setup()function (see NiftyNet's
setup()function) (highlighting only the version bit here for conciseness)
- Create a wheel by executing
pip setup.py bdist_wheel: this creates a
NiftyNet-0.1rc49-py2.py3-none-any.whlfile (note the version identifier encoded into the file name)
- Submit the created wheel to PyPI using
twine upload NiftyNet-0.1rc49-py2.py3-none-any.whl
A few remarks:
versionparameter mentioned above is a required field for the
- When creating the wheel, the
versionnumber is included not only in the file name but also in the project metadata within the wheel itself
- A wheel with a specific version number can be submitted only once (PyPI simply rejects duplicate submissions)
- Any "release candidate" would actually be a release in itself, as far as the PyPI ecosystem is concerned. For instance in this case the PyPI release would be version
A possible approach to this problem
Implement a Git hook such that:
- The developer tags a Git "version" e.g.
git tag -a 0.1rc49 -m "my release candidate 0.1rc49"
- The Git hook creates the wheel
NiftyNet-0.1rc49-py2.py3-none-any.whlfor this Git tag.
- GitLab notifies the developer in charge of pip installers.
- The developer subsequently submits the created wheel.
Unless I'm missing something, the only risk in this scenario is the developer tagging the wrong commit.
It is worth:
investigating this add-on to
setuptoolswhich fetches the version from a VCS like Git, so that it doesn't have to be hard-coded into the