Log file Viewer
#pypa-dev logs for Tuesday the 30th of June, 2015
[00:59:48] <Nakato> lifeless: What do you consider of packages installed from requirements. Should those be treated as a user requested dependancy and thus not able to be constrained or able to be constrained.
[01:07:10] <lifeless> if requirements.txt has a vcs reference or something conflicting with foo==1.3, then its a problen
[01:07:29] <lifeless> Nakato: I wouldn't stress too much about fine tuning here - because i've got a branch that replaces all of this logic
[01:08:22] <lifeless> Nakato: (if I thought you were working on do-be-deleted-tomorrow-code, I'd have said something)
[01:23:40] <Nakato> lifeless: Okay, then I'm completely lost. As from what I've gathered you want it to look like https://gist.github.com/nakato/502126093e36de231d3d ?
[01:35:50] <lifeless> Nakato: we totally ignore the specifiers of the requirements (or CLI) version of a requirement
[02:14:27] <tchaypo> lifeless: given that, to find a working lower bound, we’d need to iterate up the list of versions
[02:15:23] <tchaypo> it sounds to me like it makes more sense to put this logic in the tool that’s doing the iteration
[02:15:47] <tchaypo> if pip had a —use-lowest-version mode, and we use that, and it fails, then we’re going to increase the lower limit and try again
[02:16:22] <tchaypo> we could get the same behaviour by using the machinery we already have but setting the upper and lower bounds to the same thing (the current lowest bound) and increasing that as required
[02:16:56] <lifeless> tchaypo: except that that doesn't work when you have a resolver in play, because it will reject invalid combinations at that point
[02:17:26] <lifeless> tchaypo: so what I'd like is for generate-constraints to be able to do two runs, one for upper and one for lower, and then lower is what we test with
[02:18:45] <tchaypo> I’m not understanding what the problem is with the resolver - if it can’t find a valid combination, isn’t that just confirmation that the lower bound is broken?
[02:19:20] <tchaypo> … but I was thinking of the case where we’re changing and testing just one requirement - so it’s easy to set just that one requirement to a lower bound and then let the resolver adjust everything else as required
[02:22:16] <lifeless> e.g. to allow them to choose to use 'pip install X' not always do 'pip install -U X'
[02:22:45] <lifeless> so its not any one thing that will be held back, its some random set (specifically the union of requirements that overlap in ranges)
[02:23:43] <tchaypo> So the idea is to say that “We know that anything before this versions is broken”, so that if the resolver has backtracked all they way down to that version number, it knows that it has no valid versions left and can error early?
[02:24:24] <tchaypo> or are we wanting pip to be able to selectively upgrade packages if the installed version is less than the lower bound, without the user needing to use -U?
[02:24:59] <tchaypo> If it’s the latter case - I imagine that if we were doing that, pip would want to upgrade that requirement to the highest feasible version, right?
[02:29:03] <lifeless> and we do that because devs look at the docs online, and say oh look thats nice, and try ti, and it works
[02:32:45] <tchaypo> What’s the current behaviour if I “pip install X”, and X requires Y>=2.0, but Y==1.9 is installed?
[02:40:42] <tchaypo> does that mean we already have the behaviour we want, provided the lower bounds in the requirements are accurate?
[02:43:07] <tchaypo> I’m imagining is that we run a test with the flag that makes pip use the lowest possible version for every requirement
[02:43:48] <tchaypo> I imagine the first thing that’s going to happen is that we’ll find out that X has Y>=1.5 but Z has Y>=2.0, so there’s going to have to be some tweaking to find the common lower bound
[02:46:31] <tchaypo> but ignoring that, assume we have a useful set of lower bounds, we’re going to start to see things like X starts using a feature that isn’t introduced until Y==2.3, so when that patch is submitted the tests fail and we have to update the lower bounds
[04:19:27] <Nakato> Pushed an updated PR that addresses editable packages specifically. Going to grab lunch.
[20:26:12] <dstufft> lifeless: workign on some testing stuff real quick to try and get OSX testing, then releasing it
[21:36:10] <lifeless> dstufft: if we should ignore .egg's in the CWD (or more widely even) unless --egg or whatever the option is has been given
[21:36:25] <lifeless> dstufft: I see folk getting confused by easyinstall dropped eggs in their local dir on a regular basis
[21:36:47] <lifeless> 'why didn't pip install unittest2 work' -> because you had an egg dropped in . by easy-install
[22:04:21] <tchaypo> "[pip] rouge8 opened issue #2943: Conditional requirements comparing 'python_full_version' marker break on Python 2.7.10"
[22:37:07] <dstufft> (yea yea, I know that me wanting them to do that isn't going to make them do it)
[22:38:25] <dstufft> we don't actually detect the .eggs, setuptools inspects the sys.path, so you'd have to drop "." off the sys.path, but I'm not sure that's a thing we want to do
[22:39:17] <dstufft> mainly because I don't know if people _want_ that behavior sometimes, like if they're doing something with PYTHONPATH=.
[22:39:19] <lifeless> dstufft: '.' isn't in the path when you run 'pip install', is it ? the path to the script gets added instead I thought
[22:40:28] <lifeless> ['/home/robertc/.virtualenvs/test/bin', '/home/robertc/.virtualenvs/test/lib/python2.7', '/home/robertc/.virtualenvs/test/lib/python2.7/plat-x86_64-linux-gnu', '/home/robertc/.virtualenvs/test/lib/python2.7/lib-tk', '/home/robertc/.virtualenvs/test/lib/python2.7/lib-old', '/home/robertc/.virtualenvs/test/lib/python2.7/lib-dynload', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/home/r
[22:42:15] <lifeless> dstufft: so, python -m pip might have it, but its not a sufficient explanation for the symptoms :)
[22:45:23] <dstufft> lifeless: I think we should probably do something, not entirely sure what. Main concern would be if someone has "." in sys.path on purpose, but I don't even know if that's really a reasonable use case (biggest thing I can think of that would use that is pip install -t, but I think that ignores installed anyways)
[23:01:35] <dstufft> I hurt my back last night, so trying to think how to get it back over here so I can plug it back in heh