On Jan 9, 2014, at 4:29 AM, Bohuslav Kabrda <[email protected]> wrote:
> Hi all,
> the wheel package format, as defined in pep 427 specifies, that wheel name
> can contain an optional "build tag" [1]. This build tag is supposed to be a
> tie-breaker if two wheels have the same version. I decided that I would try
> to send a patch to upstream wheel project [2] to support adding this tag.
> I have a few questions and maybe someone here (Nick?) can help me with this:
> - Where is the "build tag" supposed to be stored in a built distribution? The
> pep doesn't seem to specify this. Should it be somewhere in METADATA or
> pydist.json?
> - How should the bdist_wheel command be told to use a "build tag"? By using
> some commandline option, e.g. "--build-tag 3"?
>
> My motivation for doing this is:
> For Fedora's Python 3.4 packaging, I'll have to unbundle the bundled
> setuptools and pip wheels and make ensurepip work differently. The best
> approach seems to be to make python3 require setuptools and pip (in other
> words, they'll always install along), so if user runs "python3 -m ensurepip",
> ensurepip won't need to do anything. This gets tricky if the same command is
> run in a virtualenv, since I don't have the bundled wheels. I've discussed
> this with Nick and we've agreed that the best solution would be to recreate
> the wheels from the system installed RPMs dynamically and then installing
> these wheels into virtualenv (I've already done some progress on this front
> with a small project that I call rewheel [3]). I'm now working on a
> downstream patch of ensurepip, that would use rewheel to do this.
> Now let me explain a bit about how we package setuptools/pip in Fedora. When
> there is a security issue or just a bug in a package, we don't upgrade it to
> latest upstream version in stable Fedora releases, since as a distribution we
> try to maintain API/ABI stability. We rather bump the "release" (which is
> sort of downstream version of the package). E.g. if there is a bug in package
> pip-%{version}-%{release}, we fix it and bump it to
> pip-%{version}-%{release+1}. But that means that if we fix a package and
> someone runs "python -m ensurepip --upgrade", he won't get the fix into
> virtualenv because the version is the same. That's why I'd like to use
> Fedora's release as the "build tag", so that this use case would work. I hope
> this all makes some sense :)
>
>
> Thanks!
>
> --
> Regards,
> Bohuslav "Slavek" Kabrda.
>
> [1] http://www.python.org/dev/peps/pep-0427/#file-name-convention
> [2] https://bitbucket.org/dholth/wheel/
> [3] https://github.com/bkabrda/rewheel
> _______________________________________________
> Distutils-SIG maillist - [email protected]
> https://mail.python.org/mailman/listinfo/distutils-sig
I’m not entirely sure the build tag actually works at this point in time. It
might though.
Another option would be to use the local version number as specified in PEP440.
So
if you have pip 1.5 bundled, and you change something, you make it pip 1.5-1,
then if
another change comes out you make it pip 1.5-2, etc. Again this might not work
exactly
right at the moment as this is a case that hasn’t been well tested yet and it
might be
seen as a pre-release.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
