[02:11:16] <Nakato> lifeless: That pull request is ready for another look. https://github.com/pypa/pip/pull/2937
[06:34:00] <sontek> Hey, so we recently ran into issues because unittest2 actually uses an object for their version which works for `install` but for whatever reason doesn't for `wheel`. I tracked this down in setupools because it tries to use a regex on the version passed in which happens to be an object not a string
[06:34:26] <sontek> so if you `pip wheel unittest2` it blows up
[06:34:51] <sontek> I've opened a PR here with some discussion: https://github.com/pypa/packaging/pull/36 wondering if that is an ok approach
[06:35:15] <sontek> I realize this object should probably go through `LegacyVersion` but it seems quite harmless to support __str__ within `Version` as well
[08:00:09] <lifeless> sontek: I've been building and publishing unittest2 wheels fora while
[08:00:13] <lifeless> so this doesn't make sense to me :)
[09:01:09] <ronny> lifeless: sup, is it finally possible to disable the complete usage of wheel caching ?
[09:02:10] <lifeless> ronny: I have made no changes in that space. Its as possible as it was before.
[09:02:20] <lifeless> ronny: (which is entirely so, but it is a big hammer)
[09:03:30] <ronny> lifeless: the behaviour i noticed when i disabled wheels was that pip would aslo not fetch universal wheels availiable on pypi
[09:03:58] <lifeless> that is indeed the expected outcome
[09:04:41] <ronny> lifeless: i kinda want those - bascially i need the behaviour of pip install --download of pip 6.x back
[09:05:18] <lifeless> have you opened an issue with a description of the problem?
[09:06:15] <ronny> i created a few issues wrt the behaviour and one to create a fetch command, whiche would behave like pip install --download did in 6.x
[09:06:29] <ronny> unfortunately i couldnt quite work on it
[09:09:14] <lifeless> whats your github user handle?
[09:09:34] <ronny> lifeless: my unsterstanding is that bascially to kill -- download and get things nice again, all i'd have to do is move the logic to a fetch command that would not create a wheel_cache object
[09:18:49] <lifeless> we can't meet setup_requires needs (1), we can't process projects that can't build on this python at all (e.g. 2.x only or 3.x only) to figure out their deps (2)
[09:19:03] <lifeless> both 1 and 2 will break the copy-over-the-network case
[09:19:35] <lifeless> dropping the source tar in the download dir when wheels were autobuilt would be easy enough, but it doesn't meet the described needs in the bugs
[11:31:33] <ronny> lifeless: basically all i want is not using the wheel cache functionality when i do package downloads
[15:06:54] <sontek> lifeless: have you tried running pip wheel unittest2 --no-use-wheel on it?
[15:48:55] <sigmavirus24> sontek: critical information that's possibly missing, what version of python are you running 'pip wheel' under?
[15:49:49] <sontek> sigmavirus24: it happens under 2.7 and 3.4
[15:50:50] <sontek> you can just do `mktmpenv; pip install wheel; pip wheel unittest2 --no-use-wheel` if you have virtualenvwrapper to see it
[15:51:28] <sontek> and add -p /usr/bin/python3.4 to mktmpenv to see if fail on 3
[15:54:42] <sigmavirus24> lifeless: I can confirm: http://paste.openstack.org/show/358902/
[15:56:58] <sontek> This PR has a test + fix for it but not sure if its completely correct: https://github.com/pypa/packaging/pull/36
[15:57:33] <sontek> If setuptools detected this object as a `LegacyVersion` then it would work, but since setuptools doesn't use `LegacyVersion` it has to go through `Version` so thats where I made the fix
[15:58:21] <sontek> That was discussed a bit here: https://bitbucket.org/pypa/setuptools/pull-request/139/safe_version-call-str-on-version/diff
[17:27:27] <sontek> dstufft: Why did you land on using environment variables instead of YAML?
[17:27:44] <sontek> dstufft: We just recently decided to go the other way and get rid of env vars :P
[17:28:26] <dstufft> sontek: with all likelihood Warehouse is going to be deployed onto Heroku (and if not Heroku, probably Openshift Origin v3) which both use env vars as configuration
[17:29:34] <sontek> ahh, I guess if you are using something like that it makes sense. We manage our own infrastructure and deploying an application where we want to reload the environment variables is kind of wonky
[17:29:44] <sontek> we end up setting them all in supervisord.conf
[17:30:41] <sontek> We use our own YAML loader that can pull from environment though: https://github.com/SurveyMonkey/pyramid_cli/blob/master/pyramid_cli/config/yaml.py#L70
[17:30:49] <sontek> so you still have YAML either way
[17:31:56] <dstufft> I thought about doing something like that (possibly via montague), but it felt counter productive to fight the platform's desired configuration mechanism and my config needs are fairly low anyways
[19:08:38] <lifeless> sontek: the ugly I have doesn't really work in all cases anyhow - still race conditions etc.
[19:08:52] <lifeless> sontek: so I still don't see the point of trying to make it work in every case
[20:22:58] <sontek> lifeless: Yeah, I'm not sure if its worth it but I think its reasonable to support getting __str__ from the version
[20:23:16] <sontek> lifeless: but in general we just want our applications to not blow up when we are generating wheels =)
[20:23:37] <sontek> lifeless: Our CI infrastructure runs `pip wheel <app>` and uploads them to devpi and it blows up currently on unittest2
[20:25:33] <dstufft> the distutils docs does explicitly document the version argument as "a short string"
[20:33:18] <sontek> Yeah, so if we specifically want to state it must be an instance of str and not just implements string abilities thats fine as well
[20:33:29] <sontek> We can put validation in place and provide a nicer error message
[20:36:52] <dstufft> I don't care what the solution is fwiw
[20:37:58] <lifeless> sontek: I don't understand why you're rebuilding the wheels I upload though
[20:48:14] <sontek> lifeless: We use our own private index with devpi and move things in that way and not everyone on pypi ships up wheels and not everyone has universal wheels
[20:48:33] <sontek> lifeless: so we either special case the very few people who do build wheels or have universal ones or we just have "one way to do it"
[20:49:00] <sontek> so our standard process is to always run `pip wheel <app>` which then builds wheels for the app and its dependencies
[20:55:05] <lifeless> sontek: the bit I don't get is the use of --no-use-wheel
[21:03:48] <sontek> to ignore pips auto wheel cache and everything. We build our own wheels on our own index. pip gets confused when you mix using pypy/py3/py27 on the same box with its cache