Log file Viewer
#pypa logs for Monday the 25th of August, 2014
[06:41:45] <nanonyme> dstufft, now if only that was available in Debian repository, it would solve the chicken and the egg problem :)
[14:54:16] <tomprince> ionelmc: I don't think there is a way currently to retry. But I think that is planned (And maybe even implemented in master?)
[14:59:36] <dstufft> ionelmc: we're not going to stop vendoring, about the only option to stop vendoring is to tstop relying on dependencies all together
[15:02:16] <dstufft> ionelmc: because ``pip install --upgrade requests`` shouldn't render pip inoperable
[15:03:28] <ionelmc> dstufft: fair, but what if pip would disallow upgrades that wouldn't be "compatible" (don't match requirements in dependees)
[15:04:40] <dstufft> ionelmc: some plans sure, even then though, pip is what I call an incidental dependency. I wouldn't want to have to upgrade my app
[15:05:15] <dstufft> I wouldn't want to have to upgrade (or downgrade) my app's use of requests, just because I'm using a different version of pip
[15:05:47] <dstufft> it's "incidental" because it has nothing to do with my project, it just happens to be installed into the same envrionment because that's the only way to do it
[15:06:46] <dstufft> yes, but that doesn't help pip except in that certain versions of pip suddenly beomes incompatible with some projects
[15:08:27] <ionelmc> you shouldn't be able to upgrade a package if said package depends on newer stuff that breaks already installed packages (a <<<conflict>>>)
[15:11:26] <dstufft> theortically we have a pacakge database of installed packages, though we don't record all the info we need for it
[15:11:47] <ionelmc> i mean a state database (that knows what is installed and what metadata it has)
[15:13:41] <tomprince> The only way it could stop vendoring, is if it was installed in an isolated environment, seperate from the environment to which it is installed.
[15:13:55] <ionelmc> tomprince: otherwise it would be ridiculous, like having a python runtime beeing included in the yum bin
[15:14:28] <dstufft> the difference between yum and pip is that there generally aren't two incompatible versions of python that yum can install
[15:14:53] <ionelmc> afaik yum and apt don't do that, if you uninstall python you're essentially fuxing up your machine
[15:15:36] <dstufft> right, but what i'm saying is that yum upgrade python is never going to break yum
[15:16:28] <ionelmc> well yes, cause the package manager doesn't let you upgrade to python3 when yum only runs on py2, duuh ;-)
[15:16:59] <dstufft> people don't expect to be able to yum install different versions of python-requests
[15:18:36] <dstufft> we're going to force everyone who uses requests themselves to upgrade their own use of requests
[15:18:52] <ionelmc> dstufft: i would assume people use virtualenvs for their `apps` - so they wouldn't care about what's installed globally
[15:19:14] <dstufft> but it doesn't matter if they use virtualenv, pip gets installed into a virtualenv too
[15:19:47] <dstufft> it would be impossible to install both pip that uses requests >= 2.3 and anything else that uses an older version of requests
[15:20:59] <dstufft> this problem generally doesn't happen with apt/yum/etc, because most everything for the same OS version is going to rely on the same set of stuff
[15:21:43] <ionelmc> but i would be nice if i had the tools to achieve this: `i want to upgrade pip's vendored requests`
[15:22:50] <dstufft> I don't think requests should vendor anything, but me and kenneth disagree with that
[15:23:18] <dstufft> virtualenv doesn't exactly vendor anything, it does have two .whl files in order to install them though
[15:24:20] <dstufft> pip doesn't generally support upgrading it's dependencies (infract Ubuntu 14.04 unbundles dependencies of python-pip, and it's caused some problems for people)
[15:25:17] <ionelmc> dstufft: why shouldn't requests bundle urllib3 and whatever ? any discussions i can read about this?
[15:25:49] <tos9> for one it means that whenever there's a bug in urllib3 you need to wait for a requests release to unbreak requests
[15:28:04] <dstufft> ionelmc: "requests" is likely to be a dependency of your application/library, and should participate in your dependency tree, "pip" is likely to just be installed because you used a virtualenv (or because you installed Python 3.4+)
[15:28:13] <ionelmc> tos9: sure, but then again, you have the same issue in pip - to make it worse, it's compounded because pip is vendored by virtualenv
[15:28:40] <tos9> ionelmc: it sounds like dstufft agrees and is saying "yeah but there's no better solution"
[15:29:58] <tos9> ionelmc: (the only reason why I care is basically ^, which is that if I depend on requests and am waiting on a release that hurts my app)
[15:31:05] <dstufft> ionelmc: it's been awhile since i've had this discussion with him, mostly I think his claim is that requests supports vendoring itself and that's harder if urllib3 isn't vendored, also he doesn't consider the fact that requests uses urllib3 to be anything more than an implementatino detail or something
[15:31:41] <dstufft> generally I think the real reason is that dependency resolution in Python isn't very good right now wihch means vendoring more attractive
[15:33:21] <dstufft> (The problem with a more standardized vendoring, is that many packages require modifications to be able to do at, at least modifications to the import statements they make)
[15:33:45] <dstufft> if you look at pip's vendoring, you'll see that a lot of them have been modified to change ``import six`` to ``from pip._vendor import six`` etc
[15:38:06] <tomprince> pip doesn't ever run in the same process as other stuff (like setup.py) does it?
[16:12:12] <tomprince> Because, while it is is still vendoring; one could inject the dependencies via sys.path, rather than by putting them in a subpackage.
[16:37:54] <Lekensteyn> dstufft: thanks, peep looks useful, but it still seems to require manual action to build the requirements.txt file. Or am I missing somethign?
[19:40:50] <Beluki> Hi. Is it normal that 'pip list' and 'pip freeze' show a package name in lowercase, when it's actually UpperCase? (Windows, the package was installed via 'python setup.py install', not pip)
[20:00:27] <gp> I have run into an issue with my deployment. I downloading all of my requirements and then zip them so my application is self contained when it is deployed. This works fine until I just tried using the RC version of django.
[20:00:54] <gp> pip install --download "/foo/bar" "https://www.djangoproject.com/download/1.7c3/tarball/" saves the download as "tarball", not the filename that the django server sets in headers
[22:30:44] <jj995> after upgrading from Ubuntu from 13.04 to 14.04, pip isn't working right. e.g. "pip list" ends in an Exception (http://pastebin.com/HRAUMQWX). How can I fix this? should I apt-get purge python-pip; apt-get install python-pip? I tried "pip install --upgrade distribute" but that also ended in an error (http://pastebin.com/PCsGWbTr)