On Jan 4, 2019, at 12:36, Nick Coghlan firstname.lastname@example.org wrote:
On Fri, 4 Jan 2019 at 16:50, Nick Coghlan email@example.com wrote:
On Thu, 3 Jan 2019 at 11:13, Bert JW Regeer firstname.lastname@example.org wrote:
Is there some way to influence the egg info for the build when using pip wheel? Some thing like:
pip wheel git+https://github.com/org/somerepo.git@ourpatchset#egg=somerepo&egg_info=%2... +local<build number>"
Or is there a better method for dealing with this scenario?
The way auditwheel approaches this is as a "post-process the already built wheel" problem, rather than as a "modify the wheel build process" problem:
- Build the original wheel archive however you'd normally do so
- Unpack the original wheel archive
- Make any desired changes to wheel contents and/or metadata
- Repack the modified wheel (potentially with an updated RECORD file
and modified filename)
auditwheel's own utilities for doing that kind of thing are here: https://github.com/pypa/auditwheel/blob/master/auditwheel/wheeltools.py
It's also worth noting that distlib offers a helper API for modifying wheel archives without needing to write your own archive unpacking and repacking code: https://distlib.readthedocs.io/en/latest/tutorial.html#modifying-wheels
-- Nick Coghlan | email@example.com | Brisbane, Australia -- Distutils-SIG mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://firstname.lastname@example.org/message/ZRKT4...
Thanks for this information Nick, this is very helpful.
The other question I have is related to automated version number changes when using CI to do builds. At the moment we use Jenkins and we use the Jenkins build number to use egg_info with -b as well.
Modifying the wheel after the fact just to add the version number seems a little silly, especially since we are likely building from source in the first place, but there is no way (other than --global-options, but that disables all wheel support in pip) to tell pip wheel to increase the version number.
This really precludes us from having all of the features that pip wheel brings, such as isolated build environments and other such goodies (or even PEP-518/517 support).
Would it make sense to add an optional extra_version or something along those lines to PEP-517's config_settings that is to be used by build backends to append to the existing version identifier?
I can automate things like bumpversion, but setup tools has supported passing daily builds/tags for a while now and it feels weird that we are going backwards with the new interfaces where it is made more difficult to do that in an easy/sane manner.
Especially in the case of continuous integration/deployment where there is no explicit version bump anymore and the code is always moving forward. The version number of or code base has been perpetually stuck at 1.0 with the only thing increasing is the build number making it: 1.0.<build number>. A new commit per build just to increase the version (thereby triggering CI again... causing fun loops ;-), especially for branch builds where a developer may still be making more changes and the build number just needs to increase so that each build of a branch has a unique version number.
I will admit that I have yet to test if pip passes through the environment un-modified, because in that case I may just end up using the environment variable in setup.py directly.
Bert JW Regeer