[13:31:32] <jokus> Hi, how is it possible to access to anything like apache outside of a virtualenv ? The reason I am asking is I have Deb 6 which only has Py 2.6. I need 2.7 and Django 1.8 ?
[13:32:04] <jokus> Hi, how is it possible to access to anything like apache outside of a virtualenv ? The reason I am asking is I have Deb 6 which only has Py 2.6. I need 2.7 and Django 1.8
[13:35:09] <jokus> Thanks for the reply, but that is not allowed at the moment ! Its a production box.
[13:36:01] <jokus> So if i need to keep the current server as it is, how can I get 2.7 and django 1.8 installed on it so that it can run a django app ?
[13:36:22] <mgedmin> perhaps there's a python2.7 package in backports?
[13:36:44] <mgedmin> if all else fails, you can always build cpython from source
[13:37:24] <jokus> so compile py 2.7 and put it somewhere and let django know of it somehow ?
[13:38:37] <mgedmin> compile and install py2.7, create a virtualenv using -p python2.7, pip install django into that virtualenv
[13:45:35] <jokus> ok, will try that, also I don't think there will be py2.7 on backport
[19:17:52] <sontek> Ahh there we go. Its --upgrade --no-binary :all: --force-reinstall
[19:18:41] <sontek> Ok, so I can confirm that pip is mixing wheels between environments, so if I install something from py27 it gets cached and then py26 gets it
[19:18:47] <sontek> even though its not marked universal
[21:31:55] <sontek> dstufft: ok, so is there a way to solve this? I don't remember having this issue with earlier versions of pip
[21:32:33] <sontek> We have a bunch of builds in our CI system broken right now and its because if packages that says `if sys.version_info < (2,7): ..`
[21:32:49] <sontek> as far as I can tell this should be fine since none of the ones we are having issues with are marked as universal
[21:33:04] <sontek> and this isn't just py2 vs py3 its an issue within py2.6 vs py2.7
[21:33:58] <dstufft> sontek: the problem is universal means "py2 AND py3", but wheel assumes by default that if it's a pure python package it will work the same on all of either 2.x or 3.x depending on what the current version of Python is
[21:34:34] <dstufft> you're basically running into the same problem
[21:37:47] <sontek> Yeah, my only problem is that this shouldn't be an assumption of pip unless there is a way to change that assumption. If you can't guarantee you know its compatible then don't make it compatible across versions
[21:38:09] <sontek> universal=1 is the flag to say "i'm compatible" so trying to make me universal even though I've explicitly said I'm not is extremely odd behavior
[21:39:22] <dstufft> unverisal is a single wheel for 2.x _and_ 3.x
[21:39:44] <dstufft> wheel's defaults just don't work well for implicit caching given the history of things
[21:40:02] <dstufft> #3025 is about having pip override those defaults to something that would
[21:40:24] <sontek> I think it should just do safe caching, assuming things would be compatible across versions is something we all know wont work given the history
[21:47:14] <dstufft> for ones you control you can use environment markers, which are basically a static way to declare that you need certain dependencies on different versions of Python in a way that won't have this problem
[21:47:40] <sontek> dstufft: where are the docs for environment markers?
[21:48:21] <dstufft> for a more global solution it's disable wheel cache, downgrade, or submit a PR for #3025 (or wait for someone else to)
[21:49:01] <sontek> I think the first PR should be to just disable this assumption, it is using very poor judgement with the knowledge of what existing packages currently do
[21:49:16] <sontek> If people want better cache there can be an opt-in (probably using environment markers or something)
[21:49:46] <sontek> but by default pip shouldn't make this types of assumptions knowing they will break hundreds of thousands of projects
[21:50:31] <dstufft> well pip just relied on wheels defaults, but in hindsight wheel's defaults are tailored more towards a sitaution where an author is generating a wheel.
[21:51:25] <sontek> What is the newest version available that doesn't do this?
[21:52:13] <sontek> The odd thing is we have been generating wheels in our CI system for over a year now without issues, we just ran `pip wheel` on anything needing built
[21:54:07] <dstufft> was the directory you passed to pip2.7 wheel per env too?
[21:55:00] <dstufft> If they were, then you were essentially working around this issue via that
[21:55:20] <dstufft> since the wheel cache would have been per env in that case, but pip's auto cache is global
[21:55:34] <sontek> nope, we had a global PIP_WHEEL_DIR=/tmp/wheelhouse and PIP_USE_WHEEL=True
[21:56:53] <dstufft> strange, were you building pip 2.6 wheels first?
[21:57:31] <sontek> Depends on the order they declare their tox, but I'm guessing mostly yes
[21:57:43] <sontek> since most people list things in order like py26, py27, py34, pypy
[21:58:36] <dstufft> yea, so you would have a created a wheel that works for all of Python 2 using Python 2.6, so you would have gotten the < 2.7 dependency installed, and it just would have _also_ installed it on 2.7 when you dind't need it
[21:58:37] <sontek> I think the issue though is that not everyone supports py26, so sometimes you'll get a project who runs on the same build agent that only supports 2.7 or only 3.4
[21:58:50] <sontek> so the py26 wheel isn't guaranteed to be first
[22:00:15] <dstufft> sontek: to be clear, I'm not suggesting the current situation is correct, just trying to explain why it's probably wasn't a problem for you until now
[22:01:08] <sontek> dstufft: Yeah, I understand. I just can't even imagine how it got in this situation. We went to great lengths in our CI system to never have a wheel from a different environment be used
[22:01:26] <dstufft> the real solution is fixing #3025 so that pip overrides wheel's defaults
[22:01:37] <sontek> and it seems odd for the developers of pip/wheel to be like "This will probably work" when it will obviously not work
[22:01:50] <sontek> I hate using the word obviously in software, but in this specific case it seems quite obvious
[22:01:50] <dstufft> I think we just need to pass a flag to python setup.py bdist_wheel
[22:02:36] <dstufft> sontek: so in wheels' case, the defualts of "py2" or "py3" assume that you have someone at the helm building the wheel who'll test it out and such. So that makes sense to me
[22:02:57] <dstufft> it just didn't occur to me when I merged in the auto wheeling support in pip how that default would interact with this case
[22:03:09] <sontek> dstufft: yeah that makes sense because there is no cache, so you are getting a fresh wheel
[22:04:01] <dstufft> I'm kinda stretched super thin so I'm kind of always playing catch up on PR reviews and fixes and stuff
[22:35:38] <sontek> dstufft: Are there projects anywhere I can look at that use these enviornment markers?
[22:35:52] <sontek> The PEP isn't very clear on how to use them, would love to see some examples
[23:12:14] <dstufft> but you can omit the group name, so it's just :sys_platform=='win32' if you want it to always install them (assuming the enviornment markers match) and not just when the extra is selected
[23:14:59] <transit> When installing a dependency in a svn repository using a pip requirements file, how do you deal with authentication?
[23:19:38] <ronny> transit: thats svn specific, i doubt anyone here knows in detail