Log file Viewer

[03:36:19] <sixninetynine> !logs

[03:36:19] <pmxbot> http://kafka.dcpython.org/channel/pypa

[04:37:37] <dashdanw> hey all

[04:38:11] <dashdanw> i tried installing an out of date package using setup.py, and now every time i run pip install it cries that . . .

[04:38:18] <dashdanw> 'similus 0.0.0 requires PIL, which is not installed.'

[04:38:25] <dashdanw> regardless of what package im installing

[04:38:29] <dashdanw> any ideas as to why?

[11:56:47] <agronholm> is this a know problem with pip? trying "pip install pusher requests" installs urllib 1.23 which conflicts with requests, but "pip install requests pusher" installs 1.22 as expected

[11:56:55] <agronholm> *urllib3

[13:33:35] <exarkun> trying to debug https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Markus%20slackware64%20stable/builds/451/steps/tox/logs/stdio

[13:33:51] <exarkun> the job fails because _version.py doesn't exist

[13:34:04] <exarkun> _version.py is written by `setup.py update_version`

[13:34:27] <exarkun> all the interesting distutils commands are aliased to run this first: https://github.com/tahoe-lafs/tahoe-lafs/blob/master/setup.cfg

[13:34:49] <exarkun> and tox is used to drive the job: https://github.com/tahoe-lafs/tahoe-lafs/blob/master/tox.ini

[13:35:13] <exarkun> any reason to think that tox (presumably via pip) is going to trigger any of those aliased commands?

[13:35:23] <exarkun> or does it take some wildly different code path, instead?

[13:40:06] <ronny> exarkun: tox invokes sdist, and then instals from the sdist

[13:41:03] <ronny> exarkun: btw - consider setuptools_scm ?

[13:41:12] <exarkun> I didn't build any of this crap :(

[13:41:17] <ronny> (that one is a shamelss plug as im the maintainer)

[13:42:02] <exarkun> It is a perfect example of something so complicated and motivations so obscure and mysterious it will never be replaced with anything better.

[13:42:10] <ronny> exarkun: at first glance - that stuff in the setup.py is scarry

[13:43:19] <ronny> exarkun: oh - they use develop installs

[13:43:41] <exarkun> I think it is the result of a desire to _really_ work on all platforms, paranoia (probably justified) about all the things that can go wrong, an unusually strong need/desire to control exactly what version of dependencies are used, and the fact that it was started in like 2008 and has grown through all of the related python packaging troubles... without ever being overhauled.

[13:44:30] <exarkun> oh yea. skipsdist and skip_install both true...

[13:44:54] <ronny> exarkun: so it goes via pip install -e, hmm - i do wonder if any of that path does strange things

[13:45:05] <ronny> ah right

[13:45:29] <exarkun> But then I don't understand why it ever works. That failed build I linked to was of a branch but master builds seem fine. eg https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Markus%20slackware64%20stable/builds/449

[13:46:24] <ronny> exarkun: is it possible that on the branch the git based stuff breaks nad the file isnt written out?

[13:46:58] <exarkun> it doesn't seem too likely. the branch is not related to version gunk at all (well, in no way I can see).

[13:47:04] <agronholm> I love setuptools_scm – the *only* problem with it that I've experienced is with tools like pyinstaller which don't copy over the .egg_info directory so getting the release version for some lib is impossible

[13:47:18] <exarkun> or... do you mean, the git stuff just doesn't handle non-master branches _at all_ for some weird git reason?

[13:47:22] <agronholm> which is really the fault of the packaging software, not setuptools_scm per se

[13:47:31] <agronholm> but a practical issue nonetheless

[13:47:56] <ronny> exarkun: exactly that

[13:48:09] <exarkun> I added a print to the `update_version` command implementation and I don't see the print showing up ... but of course some part of the process, pip or tox I guess, could be capturing and hiding that output

[13:48:48] <exarkun> I should try to reproduce locally I suppose

[13:48:51] <ronny> exarkun: can you try if it wotks with pip install -e . on a venv?

[13:49:18] <ronny> exarkun: i hhave a different idea - what if the pip instrumentalisazion to prevent bs accidentially takes out the alias

[13:49:53] <exarkun> yea, I could definitely imagine that scenario

[13:52:26] <exarkun> yea, `pip install -e .` in a fresh venv results in an install where `python setup.py --version` gives the right output

[13:52:38] <exarkun> but I don't see my print during the install

[13:54:07] <exarkun> if I change the print to `raise SystemExit()` then `pip install -e .` dies

[13:54:36] <ronny> and with tox?

[13:56:43] <exarkun> weird ... tox also blows up w/ that

[13:57:29] <exarkun> eh I didn't reproduce the problem locally yet though, let me do that, make sure this is a valid comparison

[14:01:41] <exarkun> no, doing the naive thing does not reproduce the problem locally

[14:01:53] <ronny> exarkun: also a fun possibility CI breaks setp.cfg ^^ or the fetails for the version file

[14:03:47] <exarkun> local downgrade to the same tox version as the CI worker, 2.7, also doesn't make a difference

[14:08:02] <exarkun> checking in breaking code to upgrade_version _does_ result in that breakage showing up on CI...

[14:08:43] <exarkun> s/upgrade/update/

[14:08:47] <exarkun> So the job _does_ run the update_version command...

[14:08:57] <exarkun> so yea, maybe the implementation is broken somehow.

[14:18:43] <exarkun> yes, it is

[14:18:46] <exarkun> in some boggling way

[14:19:45] <exarkun> on other workers "git describe --tags --dirty --always" returns a string like "tahoe-lafs-1.12.1-372-ge2b9dd7"

[14:20:11] <exarkun> on this worker it returns a string like "allmydata-tahoe-1.10.0-1648-ge2b9dd70"

[14:20:53] <exarkun> I guess ... this worker is not fetching new tags

[14:21:49] <exarkun> it should since it passes `-t` to `git fetch`...

[14:21:58] <exarkun> alright I guess this is not a #pypa issue anymore. thanks for the help.

[22:00:05] <bn_work> hi, how does one uninstall pip when installed manually via `get-pip.py`?

[22:00:19] <bn_work> (I just realized my distro already has a package for it)

[22:00:25] <bn_work> and probably should use that

[22:00:32] <bn_work> (I would think)

[22:03:45] <bitdancer> That's usually best, yes. And there's no uninstall that I'm aware of, however it should be enough to delete pip from site-packages and delete the /usr/bin/pip stub script (I think :)

[22:05:09] <bn_work> i tried `python -m pip uninstall pip setuptools` per comment #2 at https://github.com/pypa/pip/issues/1892 but that just gives `/usr/bin/python: No module named pip`

[22:06:28] <bn_work> I think `get-pip.py` didn't install correctly because when I run the below I get this: https://www.irccloud.com/pastebin/3Z3BWS7I/

[22:07:07] <bn_work> (BTW, I installed pip via `sudo python get-pip.py --prefix=/usr/local/`)

[22:11:51] <bn_work> the last error is weird because `/usr/loca/bin` is definitely in the path

[22:11:57] <bn_work> for root

[22:12:33] <bn_work> (which is where pip{,2,2.7}, wheel, easy_install{,-2.7} were installed)

[22:28:05] <bn_work> bitdancer: hmm, is it because these packages were installed in `/usr/local/bin` VS `/usr/lib/python2.7/site-packages/`?

[22:28:40] <bn_work> I don't seem to have a `pip` in the latter ... :/

[23:02:54] <bn_work> bitdancer: ok, ended up blowing it away and just installing the distro version which seems to work but now when I try to install `pip install sqlpython` I get the following:

[23:03:57] <bn_work> https://www.irccloud.com/pastebin/teH75G46/pip_install_sqlpython.sh

[23:04:32] <bn_work> do I need a newer version of pip just to install this??

[23:05:27] <bn_work> don't really want to overwrite distro version to avoid confusing yum.... :/

[23:19:50] <bn_work> ok, was able to get around by just upgrading setuptools (apparently C7's version is 0.9.8 and they are now at 39?!) and then `sudo pip install sqlpython`