On 9 Jan 2014 20:35, "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.
Aye, this is currently "path less travelled" stuff, but the integrator
suffix is indeed intended to be the solution.
Between that and the wheel build tag, hopefully we can find something that
either works already, or can be made to work with a straightforward patch.
Cheers,
Nick.
>
> -----------------
> 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
