[16:21:55] <sterns> hello, I'm trying to install eyeD3, per these instructions: http://eyed3.nicfit.net/installation.html and instead of the expected v7.5, I'm getting eyeD3 0.6.18.
[16:22:28] <sterns> Can someone point me in the right direction?
[17:42:37] <_habnabit> does any pypi server have some sort of support for... parameterized wheels? i'm not sure how to describe it, but the thing i'm aiming for is not having to run multiple pypi servers because i want to build wheels for both 12.04 and 14.04 boxes
[17:43:47] <_habnabit> dstufft, is this something that people are working on or something?
[17:44:19] <dstufft> _habnabit: though all you really nee dis different URLs, so you could use different devpi indexes, or a static server with 12.04 and 14.04 diretories, though you'd still need to configure pip with the correct URL for the system you're on
[17:44:50] <_habnabit> dstufft, oh, devpi can do multiple indexes?
[17:45:00] <dstufft> _habnabit: people are talking about it on and off, the biggest thing the "binary linux wheel" problem is missing is someone whose willing to champion a particular solution and write a PEP
[17:45:09] <dstufft> _habnabit: yea, it can even inherient one index from another
[17:45:26] <_habnabit> dstufft, so i could have a source index, and two binary wheel indexes that inherit from them
[17:45:36] <dstufft> _habnabit: so you can have an index that more or less corespond to the Debian concept of an 'any' arch, and then binary indexes that inherient
[17:46:56] <_habnabit> sounds like devpi is the way to go then
[17:47:22] <_habnabit> after months and months of bitching, i finally convinced our organization that localshop needs to be replaced with something else
[17:47:23] <dstufft> you'll still need to do something like ``pip install --index-url https://mydevpi.example.com/myuser/ubuntu-14.04/, but you won't need to configure the "any" index since devpi will handle that
[18:10:55] <ronny> _habnabit: linux abi tags re currently unolved,
[19:11:17] <dstufft> nanonyme: We require an OpenSSL that's new enough to support sha256 certificates because sha1 certificates are weak (and browsers are starting to ding you for using them)
[19:11:30] <dstufft> that's the most likely cause of 2.6.5 not being able to access PyPI
[19:18:41] <dstufft> So it wasn't intentional to 2.6.5 but we know that it means older OpenSSL's can't hit us, and there's not much we can do about it :(
[19:19:05] <dstufft> CAs won't even issue sha1 cerificates anymore soon
[19:19:17] <dstufft> (if they haven't stopped issuing them yet)
[19:19:35] <dstufft> so that means 2.6.5 on Windows is going to be unable to hit more things as people's certs expire
[19:24:59] <nanonyme> We have an internal PyPI instance which helps some. Though some silly person made the index /+simple instead of /simple
[19:28:26] <nanonyme> https://pypi.python.org/pypi/devpi/1.0 guess it's this
[19:30:51] <nanonyme> dstufft, wouldn't happen to recall on the top of your head whether /+simple should be acceptable by pip?
[19:31:12] <dstufft> nanonyme: should be able to yea, lots of people use devpi and pip together
[19:31:29] <nanonyme> Guess I'd better take another look at it at work then
[19:32:50] <nanonyme> Basically the Python upgrade involves recompiling of some internal extensions for a new virtualenv + deploying Python in gazillion templates. Something nicer to do not-on-development-sprints