On Mar 21, 2014, at 04:30 AM, Bohuslav Kabrda wrote: >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. Gmane makes life on a zillion mailing lists so much more manageable. ;) >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. Many Pycons ago, Toshio, myself, Tarek, and several others discussed a scheme where by (through more indirection of course), various packaging tools could query configuration files to determine operating system specific paths. I thought it was quite a nice scheme which would have let us easily drop a conf file to declare where Debian wanted certain files installed, and Fedora or OS X, etc could declare others. Mostly this was in the context of the (now abandoned) successor to setup.py, but I think tools like pip and such could have taken advantage of that. I'd still like something like that. On Debian, Python adds a /usr/local directory to sys.path, but it's not /usr/local/lib/pythonX.Y/site-packages, it's .../dist-packages for reasons we've long hashed out and I don't want to re-open. Suffice to say that we do have a directory where `sudo pip install` could install to that would play nice with system Python but wouldn't interfere with distro packages. While I don't much like `sudo pip install` as a general recommendation, in principle we support that. Just to keep in mind when proposing this upstream that distros will have similar goals, but different concrete paths. >> 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. I read the patch, and I think I get it, but just to be clear, rewheeling only covers pip and setuptools, not arbitrary other packages, right? I still don't like introducing the circular dependency in Debian, so Piotr's suggestion is about where I think Debian should head. That is: `python3 -m ensurepip` would suggest (but not execute) to install python3-pip (our binary package providing pip for Python 3) if it's not already installed. The key thing is to make sure that pyvenv works in both cases. I'm not exactly sure about --upgrade. >> 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. Right, we wouldn't either I think. Cheers, -Barry
Attachment:
signature.asc
Description: PGP signature