Log file Viewer

[12:47:49] <SchrodingersScat> on some machines when I use pip, it will actually install an older version of what I'm installing. I don't understand it at all, and not sure if it's my distro or me doing something wrong. ie. I'll be on youtube-dl 2016.08.31 and then run a pip install youtube-dl --upgrade and then it'll grab like 2016.02.22, what have I done and how does it stop?

[13:34:16] <tdsmith> SchrodingersScat: the post-update message might be lying

[13:34:34] <SchrodingersScat> I think the version was confirming ;_;

[13:34:45] <SchrodingersScat> am I a time traveler? but only when I use pip?

[13:35:38] <tdsmith> is it possible you have multiple versions installed?

[13:35:45] <tdsmith> that does sound like a possibility worth examining though :D

[13:36:58] <SchrodingersScat> I wouldn't rule it out

[14:35:35] <pombreda> SchrodingersScat: the only thing I could think of could be: 1. the set of other packages installed at a point in time ends up resolving different versions. 2. the versions have been updated/changed on Pypi

[14:37:12] <SchrodingersScat> k, oddly I ran into a debian user that had the same problem

[14:40:34] <pombreda> SchrodingersScat: would have a frozen req files of what is installed in that virtualenv of yours, before and after running this --upgrade?

[14:42:29] <pombreda> SchrodingersScat: but more simply in this very case, https://pypi.python.org/pypi/youtube_dl/2016.08.31 has been removed from Pypi, hence my 2. applies

[14:42:53] <SchrodingersScat> hmm, k

[14:45:10] <pombreda> SchrodingersScat: you could ask on #youtube-dl

[14:47:27] <pombreda> ( as an aside, this kinda of stuffs just reinforce my thinking of why I shall always vendor or keep a copy of my deps)

[16:13:50] <dstufft> SchrodingersScat: are you on Debian/Ubuntu?

[16:15:01] <SchrodingersScat> xubuntu 16.04.1

[16:18:45] <dstufft> SchrodingersScat: the original youutube-dl, it doesn't happen to be installed from apt-get does it?

[16:22:08] <SchrodingersScat> oh hey, maybe it was

[16:25:20] <dstufft> SchrodingersScat: my guess is that it was, and you're using the Debian/Ubuntu patched pip which adds patches to prevent it from uninstalling the OS provided files, and the OS provided files are using a binary that forces a specific version. They also install to --user by default IIRC, so the new binary is likely in ~/.local/bin/ which is unlikely to be on your path'

[16:29:53] <tech2_> what is the PYTHON_INSTALL_LAYOUR environment variable for? I found that I have to unset it on an EC2 instance in order for pip to work correctly in a virtualenv.

[16:30:24] <SchrodingersScat> dstufft: could be

[16:30:40] <SchrodingersScat> removed, but also changed my update process, so

[16:30:44] <dstufft> tech2_: more debian/ubuntu hacking I think

[16:32:45] <tech2_> dstufft: it was set to "amzn", I haven't been able to find much info on it. The EC2 instances run AMI which seems to be a CentOS derivative.

[17:17:32] <pombreda> dstufft: good to know about Debian's patched pip. I reckon that I always use my own pip, but this could lead to devilish issues :)

[18:56:49] <nanonyme> dstufft, meh, doesn't everyone always add that thing to their PATH manually? :)

[21:36:50] <DanielHolth> ever hear of 'temporary failure in name resolution' problems for pypi?

[21:38:07] <DanielHolth> seems rebooting helps

[21:43:52] <DanielHolth> hosting problem nm