Log file Viewer
#pypa logs for Monday the 27th of July, 2015
[08:45:21] <keroberos> is there a way to `pip install setuptools --upgrade --install` that doesn't have it try to remove the system version of 'distribute' and fail because not root?
[10:06:42] <ronny> dstufft: btw, i'd to talk about having something like a installed wheel repository or python versions (that can be used to install packages as links instead of materealizing them in each virtualenv)
[10:09:45] <ronny> it should aslo allow one to work better with distributions or system installed packages (so a virtualenv could simply link the system installed pygtk/pyqt/lxml if applicable
[10:10:24] <ronny> and as extra bonus, allow scripts to refer to own very specific versions (so devendoring can no longer break pip for example)
[11:13:44] <jax> within a venv, how can i find out which cflags pip will use to compile packages like psycopg or mysqldb
[14:00:48] <DRMacIver> Is there some way I can persuade my local pip install to be better at caching than it is? I frequently find myself in low or zero connectivity regions and finding parts of my workflow don't work because pip refuses to install a package into the local virtualenv which it has 100% downloaded not only before but recently.
[14:01:46] <Wooble> I don't know about getting caching to work better, but sounds like a wheelhouse might be a good idea.
[14:03:20] <DRMacIver> Likely. Is there a decent way to make that work transparently though? The chances are basically zero that I will explicitly remember to put every package I regularly use in a wheelhouse.
[14:08:13] <Wooble> Not really out of the box. I suppose you could build a script that tries to install from your wheelhouse and if that doesn't work puts the package in there and then installs it, and use that instead of pip. :/
[14:10:02] <DRMacIver> I really can't. :-/ A lot of where I run into this problem is e.g. inside tox when it's trying to install its dependencies.
[14:14:41] <DRMacIver> I mean I can write that script and it would obviously be better than not having it, but it wouldn't actually help most of the cases that this is a problem.
[14:27:50] <ronny> DRMacIver: ideally devpi nd pip were integrated (so the wheel cache would be just a index inheriting from root
[15:46:54] <nafets> I've just taken a giant leap from pip 1.5.4 to 7.1.0 and am trying to install from a requirements.txt with versions like "configparser==3.3.0r2". Even though my local devpi instance has that version and pip --verbose ... prints out s "Found link ... version: 3.3.0r2" line, I get a "DistributionNotFound: No matching distribution found for configparser==3.3.0r2". Do I need to replace all those with PEP 440 normalized versions (because str(pip._vendor.packaging
[15:49:08] <nafets> i.e. does my requirements.txt have to be edited to say "configparser==3.3.0.post2" ?
[15:57:24] <nafets> if I downgrade to pip 1.5.4 then the same pip install command succeeds, though prints lines like "Requested configparser==3.3.0r2 (from -r ../conf/requirements-python.txt (line 1)), but installing version 3.3.0.post2" and pip freeze reports the ".post2" version
[16:00:30] <benjaoming> The pip / pkg_resources version order is not understood by debian: Things that are translated to "0.1a1" will NOT order before 0.1 in debian: "if dpkg --compare-versions 0.1a1 lt 0.1; then echo true; else echo false ; fi" = false
[16:00:51] <nafets> pip 1.5.4 can't reinstall from the output of pip freeze now: "Could not find a version that satisfies the requirement configparser==3.3.0.post2 (from versions: 3.2.0r1, 3.2.0r2, 3.2.0r3, 3.3.0r1, 3.3.0r2, 3.5.0b1, 3.5.0b2)"
[16:00:55] <benjaoming> Does anyone know a scheme for alpha/beta/pre-releases that can work for both pkg_resources and debian?
[16:04:04] <benjaoming> nafets: here are the versions available for configparser https://pypi.python.org/simple/configparser/
[16:05:08] <xafer> nafets, I'd say this is a pip bug due to an other bug in packaging, cf https://github.com/pypa/pip/issues/2619
[16:12:50] <benjaoming> nafets: I think you might be encountering a problem that was intentional. PIP consistently uses pkg_resources.parse_version on all your version inputs. This is the result:
[16:13:52] <benjaoming> The goal is probably to force a strict version syntax for the future, even if the packages use wrong conventions.
[16:14:54] <benjaoming> 3.3.0a1 would always order BEFORE 3.3.0... using 3.3.0r1 should make it order AFTER 3.3.0, however it's a little ambiguous to say the least.
[16:15:31] <nafets> benjaoming: I see that. Is the intention then also that I write the normalized version string in my requirements.txt file?
[16:15:51] <nafets> benjaoming: r1 is an allowed spelling for post-releases https://www.python.org/dev/peps/pep-0440/#post-release-spelling
[16:16:08] <benjaoming> Yes, I think you should use "3.3.0.post2" because you actually get the correct package, the 3.3.0r2
[16:18:15] <nafets> that's what I've done for now :-) it's a little annoying though and not terribly newbie friendly since (until the day when all of PyPI uses normalized version strings) they'll need to go out and learn these normalization rules before they can install anything
[17:33:52] <benjaoming> Okay I here's my analysis of debian versions vs. PEP-440... https://overtag.dk/wordpress/2015/07/versioning-your-python-project/ -- any comments for the conclusion that I reach about manipulating upstream version numbers?
[19:51:13] <jax> well the problem is, i had to recompile the system to remove AMD optimization, so i removed -march=native from gcc and recompiled python and all system python packages
[19:57:30] <carljm> jax: No, there is no easier way that I know of other than to do them one by one (or write your own automation).
[19:58:13] <carljm> virtualenv itself doesn't know anything about where you might have virtualenvs on your system; there's no central registry of virtualenvs to work from.
[19:58:57] <jax> i just do something like for v in `lsvirtualenv -b`; do echo $v; workon $v; pip install --upgrade pip; done
[19:59:54] <carljm> Or know what compiled packages might be installed, so you can uninstall them and then do `pip install -r reqs.txt`
[20:01:06] <carljm> In that case you really should just blow away each env and recreate, you need to copy in the new executable too
[20:01:34] <carljm> Deleting and recreating won't take significantly longer than `pip install -r reqs.txt --ignore-installed`
[20:01:49] <carljm> The time to create a venv will be dominated by the time to compile its contents, most likely.
[20:02:34] <carljm> Yes, you'd need to manually handle anything you care about (like postactivate scripts) that you store inside the env.
[20:03:06] <carljm> You may be able to get away with copying the executable in yourself, along with the pip reinstall, if that's easier than handling postactivate.
[22:08:22] <carljm> jax: It's just a wheel. A wheel is a type of "binary distribution", thus "bdist" in historical distutils terminology.