Log file Viewer
#pypa-dev logs for Monday the 24th of March, 2014
[09:06:12] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[09:06:12] <pmxbot> Remove test_build_egg. The test doesn't work and it's difficult to test _build_egg given the current interface.
[09:06:12] <pmxbot> Remove test_do_download, which also no longer works due to complexities around secure downloaders.
[11:00:33] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[11:00:33] <pmxbot> Remove test for use_setuptools, as it fails when running under pytest because the installed version of setuptools is already present.
[11:00:33] <pmxbot> Just remove test_ez_setup, as the last remaining test, test_install, only barely touches the functionality as the actually installation command is mocked. The test run in the travis config is much more comprehensive.
[18:59:21] <Ivo> dstufft: what do you mean by broken here https://github.com/pypa/pip/issues/1668#issuecomment-38460127
[19:04:42] <dstufft> Debian didn't permanently break it though, they are looking to re-add it back in
[19:07:39] <Ivo> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python
[19:11:53] <dstufft> I think they just took a scorched earth policy while they figure out what they are going to do
[19:12:06] <Ivo> my naive assumption is surely you'll get a cleaner outcome by using the configure option the maintainer of the upstream nicely provided for you
[19:12:44] <dstufft> --without-ensurepip only prevents pip being installed into the global site-packages
[19:13:28] <dstufft> what debian did was use --without-ensurepip to prevent it from being installed into the global site-packages, but then also removed the module from the stdlib all together
[19:14:26] <Ivo> I always thought that venv was going to provide basic plumbing, and let something like virtualenv implement niceties over the top of it, like installing an pip
[19:14:54] <dstufft> with 3.4 the built in venv module is basically a complete replacement of virtualenv
[19:15:33] <Ivo> I don't really like this 'well since we have a bundled pip dagging around, may as well chuck it in with the venv module as well'
[19:16:17] <Ivo> trying to get too much right, and the pip module will be static with the python version
[19:16:50] <dstufft> if it's good enough for the global site-packages it should be good enough for a venv
[19:17:30] <dstufft> and something like virtualenv can still provide a shim over the venv module and provide newer pip if someone wants that
[19:18:18] <dstufft> It's kind of asymetric for Python to have ``pip`` available by default in the global site-packages, but not have it available in a venv
[19:20:48] <Ivo> i think it'd be asymmetric if python just bundled pip straight out, instead of a bootstrap module
[19:42:11] <Ivo> dstufft: I always thought virtualenv would transition over to using venv instead of its own incantations when it found it was running on python >=3.3
[19:42:51] <dstufft> but there's very little reason to keep ensurepip in the stdlib at all if it's just an install time thing
[19:46:31] <Ivo> unfortunately that also suffers from noone making use of new features in python because who runs a newish python in production rite!?
[19:49:07] <dstufft> ensurepip is in the python stdlib, the python.org provided binaries call it by defualt
[19:52:35] <Ivo> soooo, thinking in irc messages... python is now trying to provide a package manager, i.e make pip its official package manager, like ruby does with gem and node does with npm... but since it once was a '3rd party' package manager, distros don't know how to react?
[19:53:41] <dstufft> if we just committed it straight to the stdlib then they would have just allowed it
[19:54:05] <dstufft> but instead we put an installer in the stdlib and bundled a package inside it and install it
[19:54:38] <Ivo> but not only that, we also make use of that to enable the shared nothing architecture that is a venv
[19:55:30] <Ivo> because you use that wheel to install a separate pip into a venv, which is now a feature of python (if you don't go removing stuff)
[19:55:51] <dstufft> for instance: If they want to patch pip to use the system provided certificates instead of the bundled ones, they have to patch the one provided by python-pip, and they have to unpack the Wheel, patch that pip, and repack the Wheel, and then stick it back inside
[19:56:28] <Ivo> so it would be less of a problem if we were more like node, in that the npm that handles a local node env is the same one that does global installs (you just add -g in your invocation)
[19:59:13] <dstufft> The reason we didn't do that is we wanted to be able to independetly upgrade pip in an rleady installed environment
[19:59:58] <dstufft> e.g they way we did it, even if you'er stuck on 3.4.0 and pip 1.5.4, but you want the latest pip (1.9 let's say), you're only a pip install --upgrade pip away from that
[20:02:32] <dstufft> well that's what it does more or less, it just does the unpacking of a Wheel at install time rather than commiting it to the repo
[20:23:57] <dstufft> Ivo: there were concerns about that which I don't recall exactly, and venv doesn't include the system site-pacakges by default either
[20:24:51] <Ivo> that was why i was asking about whether you'd roll back the venv-includes-a-copy-of-pip feature
[20:32:22] <Ivo> well the example you gave, ca certificates, seems a bit hypocritical that they made no fuss about virtualenv vendoring zips
[20:35:04] <dstufft> Well python is a bigger deal than virtualenv, and I wouldn't exactly call it making a big fuss or anything
[20:35:34] <dstufft> for instance: one thing PEP453 does is recommend installing python-pip with Python
[20:37:15] <Ivo> imho the deliniation should be made on whether something is system-y or developer-y. ensurepip's copy of pip is developer-y, so system maintainer shouldn't be trying to mess with it
[20:37:30] <dstufft> Fedora is planning on introducing a circular dependency for that, Debian doesn't want to do that because a circular dependency is kind of icky
[20:37:44] <dstufft> also pip is a developer facing tool in their eyes, but Debian isn't just a developer facing OS
[20:38:37] <Ivo> well the problem is vanilla pip by default is modifying the system python and system path, so I'd say it has to be considered system-y
[20:42:37] <dstufft> the proposals for --user by default don't affect what it'd do if you install it as root
[20:50:03] <Ivo> but isnt the point that once --user is default, people won't be inclined to be running pip with root anymore
[20:52:35] <Ivo> which is also what some debianers are complaining about in these MLs - 'pip, get off ma /usr'
[20:53:57] <tomprince> I found the comment about installing to /usr/local/lib/.../dist-packages crazy.
[20:54:20] <tomprince> I thought the point of having dist-packages was so that /usr/local/lib/..../site-packages was for admin installed stuff.
[20:58:21] <Ivo> i was thinking debian's python debs installed to one dir and direct distutils to install to another, but sort both in sys.path
[20:58:23] <dstufft> it's a temporary thing while they figure out how the policies apply and what they want to do exactly
[20:59:04] <tomprince> Ivo: I think that was the intention of introducting dist-packages, but I don't think that is the reality.
[21:00:48] <dstufft> jezdez: but afaik all of Ubuntu's internal stuff uses 3.4 in the latest LTS, and python 3.4 is preinstalled but python2 requires an apt-get
[21:02:11] <tomprince> Oh. Reading https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/362570 suggests that dist-packages in /usr/local is to distinguish from a manually installed python in /usr/local
[21:03:03] <dstufft> Ivo: I would maybe consider using arch for a desktop if I ever left the land of Apple
[21:04:01] <dstufft> but yea, right now the various linux distros support (or don't) PEP453 to varying degrees while they figure out how mad they are at PEP453/me
[21:04:33] <Ivo> dstufft: you get either the latest version of a thing after a week or two, or at its .1 release if its big and probably needs a bug release
[21:04:49] <dstufft> but afaict most of them are probably going to enable it at least for the venv module
[21:05:39] <dstufft> Fedora is got some thing which will dynamically generate a Wheel from an already intalled pip
[21:05:48] <Ivo> i essentially think they'd be a lot less scared if pip already had '--user by default'ish behaviour
[21:09:42] <Ivo> pip could always detect whether that wasn't currently on path and inform you of such
[21:18:13] <dstufft> that doesn't itself mean that we can't do it, just that it's something to think of
[21:43:11] <Ivo> apparently a shipping container falls off a boat somewhere in the world about once an hour