The wheel build tag is only stored in the filename. The feature is not
well tested.
On Thu, Jan 9, 2014 at 7:35 AM, Donald Stufft <don...@stufft.io> wrote:
>
> On Jan 9, 2014, at 4:29 AM, Bohuslav Kabrda <bkab...@redhat.com> 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 - Distutils-SIG@python.org
>> 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
>
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
