On Mar 25, 2014, at 2:59 AM, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
----- Original Message -----
>> I would say this one https://github.com/pypa/pip/issues/1351
>> for us
>> as packagers. It makes me nervous/upset and sad altogether :-).
> Awesome, well that’s on the list for 1.6 so that should be the next feature
> of pip.
Cool, thanks a lot!
>>> having it tied so closely to Python. Also generally about making less
>>> for distros where pip is involved (pip and the OS package manager stomping
>>> each other etc).
>>> To start off this goal I've filed
>>> figure out how pip can get our defaults to the point where most users will
>>> installing to ~/.local/ instead of the system location. If there's more
>>> pip can do I'd love to know about them, or if ensurepip or the PEP453
>>> have something I can help with too :)
>> Nice, I have put my two cents in it.
> On the topic of re-wheeling (Sorry I just joined so I don’t have it in my
> history to reply to).
> I’m assuming Fedora unbundles the stuff that pip bundles (sorry :/) and I’m
> guessing that
> since the Rewheeling is going to pull in the system versions that it’s going
> to pull in a
> copy of pip with those things unbundled. If that’s the case you’re going to
> need to install
> those things into the virtualenv itself.
Just yesterday, I took ownership of python-pip in Fedora and I'm quite surprised that
we don't unbundle anything. I'll have to investigate this. It actually makes sense
now that I think of it, since the rewheeled pip has worked for us in virtualenv - had we
unbundled the bundled code, it would have failed.
Ah I just assumed y’all did, that actually makes sense now why you hadn’t run into that
issue yet :)
> However I think that the copy of pip inside of a venv should keep stuff
> bundled if at all
> possible. One of the reasons we did this was so that when using pip inside of
> a venv
> we don’t make any assertions about what other things you can have installed.
> So for
> example we depend on requests, we don’t want someone who is using an older
> (or newer!)
> requests inside of their venv to be unable to install it because pip itself
> uses it. Also
> another reason we did that is because if you uninstall one of those things
> and it breaks
> pip you don’t really have a good way to unbreak it except destroy the venv or
> install it
> manually. This is less of a concern for the system installed pip because you
> have yum
> or whatever that can be used to fix it and y’all integrate things already to
> ensure compat :)
Maybe the reasons for you to bundle are also the reasons why Fedora's pip doesn't
have these libraries unbundled. As I've said, I need to investigate this.
For what it’s worth, we do attempt to make it easy for the system level pip to have it’s
copies of stuff unbundled, but if you keep it bundled and use rewheel it’ll be easier to
do modifications to it than having the system pip and the “bundled” pip have different
sources. Because the pip source just bundles stuff as part of it’s source while the venv
source has it inside a Wheel so you have to do an unpack, modify, repack dance that
rewheel will do for you.
FWIW the technique used by Python for PEP453 matches what we already were doing in the
virtualenv package, so if you modify the behavior there, it might be reasonable to also
modify it in virtualenv to use rewheel. That would also cut down on the number of
different sources of pip.
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
python-devel mailing list
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA