Log file Viewer

[02:36:14] <gtback> Not that it helps, but it looks like the first error is when pip is checking to see if it's up to date.

[02:36:23] <gtback> That's why there are two.

[02:37:15] <gtback> Definitely looks like a bug, but I'm not sure why it's only on 15.04.

[02:37:38] <gtback> And the error actually comes from error handling code. Ironic!

[02:56:18] <warner> hey, so I'm trying to investigate an incompatibility between Versioneer and the console_scripts generated by (some versions of?) setuptools/pip/easy_install/wheel/something

[02:56:50] <warner> sometimes I get a console_script that contains "EASY-INSTALL-ENTRY-SCRIPT" and a call to pkg_resources.load_entry_point, which hard-codes the expected version string

[02:57:33] <warner> (this causes problems with versioneer-managed projects, especially when you 'setup.py develop' into a virtualenv, since the version string changes each time you make a commit, and the script then requires an outdated version)

[02:58:08] <warner> but sometimes I get a simpler one that just does "from PROJECT import main", a little sys.argv[0] rewriting, and then "sys.exit(main())"

[02:58:15] <warner> this simpler form works fine

[02:58:40] <warner> I'm wondering if anyone can help me figure out the circumstances under which the simpler form is created, vs the pkg_resources-based form

[02:59:28] <warner> I see the template for the pkg_resources form in the setuptools source tree, where I believe it's used by the easy_install command

[03:23:25] <warner> ah, after more experimentation, it seems like "setup.py develop" / "pip install -e" results in the pkg_resources/load_entry_point form that pins the version, while "setup.py install" / "pip install" give the simpler form that just imports-and-runs

[03:23:40] <warner> which is a shame, because that's backwards from what the Versioneer use case needs :)

[03:24:26] <warner> some of the /usr/bin executables on my debian box use the pkg_resources form.. I wonder if that's some artifact of a debian packaging tool

[03:27:56] <dstufft> warner: the simpler one happens when pip installs from wheels

[03:28:05] <dstufft> the othe rone happens every other time

[03:28:11] <warner> ah.. wheels

[03:28:13] <warner> thanks

[03:28:44] <dstufft> but in pip 7, we auto build wheels (assuming the wheel project is isntalled and building a wheel didn't fail)

[03:31:20] <warner> cool

[03:31:42] <warner> yeah, so develop/-e is still going to use the form that causes Versioneer problems

[03:32:31] <warner> I suppose a (painful) workaround would be to install without -e, stash a copy of the console script, uninstall, install again (with -e), then overwrite the pkg_resource -using script with the copy

[03:33:04] <dstufft> or make python -m <your thing> work

[03:33:11] <dstufft> and just use that exlusively in dev

[03:33:21] <warner> yeah, moshez is encouraging me on that one in #twisted :)

[07:48:04] <nikolaosk> is it possible to declare version conflicts with setuptools?

[07:48:54] <nikolaosk> or even plain conflicts between packages

[19:23:37] <t3chguy> I installed `python3-pip` on Ubuntu 15.04 but am getting an error each time I run `pip3 list`, an AssertionError to be more specific: http://hastebin.com/enixotodiz

[19:23:40] <t3chguy> Any ideas?