Re: Python 3.4 and ensurepip (rehashed, long)
----- Original Message -----
> Thanks for following up here, and welcome to the list! I lurk on the Fedora
> list via Gmane, but I don't think I have posting privileges there.
> Responding
> a bit out of order.
Thanks!
> On Mar 20, 2014, at 04:53 AM, Bohuslav Kabrda wrote:
>
> >I'll be glad to discuss this/answer all questions that might arise about our
> >approach. I'd really love to see it as a general cross-distro approach.
>
> I agree that a cross-platform approach is best, if possible. This may not be
> the best place to hash something out though, since we probably won't reach
> many other platforms (even Linux-based ones). Maybe python-dev or the
> pypa-dev list?
I'm on python-dev but not pypa-dev. But if you want to take the discussion there, I guess I'm ok with following yet another mailing list.
> I have a number of questions and issues with the downstream
> recommendations of PEP 453. If you'll be at Pycon, that might also be a good
> place to discuss.
Yeah, I also have some issues with current recommendations of PEP 453 and it'd be great to get together and discuss. I'm not going to Pycon, but I'll be at DevNation in April and I'll also go to this year's EuroPython. Any chance to catch you at one of these?
> >Basically, we'll add runtime deps on setuptools and pip to python3 package,
>
> Doesn't that introduce a dependency cycle? If so, does that bother you?
It does introduce a dependency cycle, which I don't like very much, but I think it's the best solution from user (read: developer) perspective, so we'll most likely be going with that.
> I don't particularly like it for Debian, but for Ubuntu it's a bigger problem
> because python-pip is in universe so it would require a MIR to pull that into
> main and avoid a cross-pocket dependency (on top of the dependency cycle it
> would introduce).
>
> >so systemwide "python3 -m ensurepip" won't actually do anything, since
> >setuptools and pip will already be there.
>
> With a reliable way to say "we are not in a virtualenv", I wouldn't mind if
> on
> Debian, a systemwide `python3 -m ensurepip` would recommend installing the
> python3-pip if it's not installed, much like command-not-found will do. It
> could also discourage the use of pip for the system Python (when --user is
> not
> given). Do Fedora users often want to pip install random PyPI packages into
> the system Python?
Yep, they do that. That's actually another thing that we're working on right now - creating an upstream-acceptable patch that would make all system-wide pip installations go into /usr/local/lib/..., while system-wide RPM installed packages would install into /usr/lib/... We know that Debian already has some downstream patches for this and there is also a bug opened for this upstream [1].
But yeah, currently users just "sudo pip install foo" into system Python packages path.
> >In virtualenv, our custom "rewheel" script (see the referenced mail for more
> >info/links) will repack the system setuptools and pip to wheels archives and
> >install them into the virtualenv. I've been discussing this with Nick
> >Coghlan quite extensively and he generally likes the approach, so we'll
> >probably be trying to push it upstream for Python 3.5 (our patch is general,
> >so it should work on any distro or even with vanilla upstream ensurepip).
>
> What will rewheeling prefer when:
>
> * bundled ones are newer than system ones?
That's not currently implemented in our patch, since we'll be removing bundled wheels and relying on system versions only. But to solve this situation for the upstream patch, we'll do it like this
- if user runs just "python3 -m ensurepip", nothing will happen
- if user runs "python3 -m ensurepip --upgrade", his setuptools/pip will get upgraded
Note, that this corresponds with current ensurepip documentation [2] of such situations.
> * newer versions are available on PyPI?
Nothing. The current upstream ensurepip newer touches PyPI either, it only works with bundled wheels.
> * --upgrade is given?
See above.
> Does using --system-site-packages affect rewheeling?
Not sure ATM, will have to check... but it doesn't, I think.
> I'm not sure what we would do if we wanted avoided the dependency cycle, and
> pip/setuptools wasn't yet installed system wide.
Yeah, that's a tough one and it's actually one of the reasons why we decided to introduce the dependency cycle. The obvious (and IMO wrong) solution would be subprocess.Popen(['sudo', 'yum', 'install', 'python-pip']), but that just isn't something that I'd want to do.
> Cheers,
> -Barry
Regards,
Slavek.
[1] http://bugs.python.org/issue1298835
[2] https://python.readthedocs.org/en/latest/library/ensurepip.html#command-line-interface
Reply to: