pmxbot IRC Log Viewer

[02:25:27] <dstufft> tomprince: qwcode sigmavirus24_awa yea, my intention long term is to remove distlib from pip by using packaging or so, but I'm not willing to start adding non-standard things to packaging to do it. So it's slow progress!

[02:46:43] <jaraco> dstufft: did you see https://bitbucket.org/pypa/setuptools/issue/320/error-when-upgrading-to-1001-via-pip

[02:46:43] <jaraco> Do you know how pip invokes setup.py for sdist packages being installed?

[02:46:53] <dstufft> jaraco: I hadn't seen it

[02:46:58] <dstufft> we invoke it in a terrible way

[02:46:59] <dstufft> :/

[02:47:03] <dstufft> sec let me look up the code

[02:47:10] <dstufft> we do a hack to force things to use setuptools

[02:47:30] <jaraco> Is it invoked in-process?

[02:47:41] <jaraco> (vs. subprocess)?

[02:48:37] <dstufft> subprocess

[02:49:30] <dstufft> https://github.com/pypa/pip/blob/develop/pip/req/req_install.py#L303-L356 here is where we run setup.py egg_info

[02:54:01] <jaraco> dstufft: given that it's run using a subprocess, I'm surprised that error emerges.

[02:54:22] <jaraco> Because setuptools 10.0.1 doesn't have the metadata entry that would cause that function to be looked up.

[02:54:29] <jaraco> (I'm confirming that in the sdist now)

[02:55:42] <dstufft> jaraco: going from 8.2.1 to 10.0.1 works fine for me fwiw

[02:56:05] <dstufft> oh

[02:56:11] <dstufft> on 12.04 only it seems

[02:56:13] <dstufft> and using pip 1.4

[02:56:43] <dstufft> the second guy was using pip 6

[02:57:03] <dstufft> wonder what version of setuptools they were starting with

[02:57:33] <dstufft> 12.04 ships with 0.6.24-1ubuntu1

[03:02:07] <jaraco> I confirmed that setuptools 10.0.1 does not have the file finder, so that error is apparently coming from metadata from another setuptools installation.

[03:02:40] <dstufft> jaraco: we do this when we run egg_info, could this be causing it? -> https://github.com/pypa/pip/blob/develop/pip/req/req_install.py#L375-L396

[03:03:06] <dstufft> we don't do ``python setup.py egg_info``, we do ``python -c `` that ^

[03:04:03] <spulec> (I opened the ticket)

[03:04:14] <spulec> I believe the machines were originally on 10.0.0, but I can confirm that

[03:05:50] <jaraco> dstufft: My initial reaction is no. It actually looks like a workaround.

[03:06:34] <jaraco> (for a similar issue)

[03:06:36] <dstufft> (I can't wait until we don't have to execute setup.py to install some stuff)

[03:06:41] <jaraco> I wonder if the "python -c" affects the sys.path such that the local .egg-info is not honored.

[03:10:08] <spulec> sorry, the original ticket was not complete. there is also some distribute stuff mixed in here. I originally has distribute==0.6.24 installed

[03:10:35] <dstufft> were you upgrading from distribute to 10.0.1?

[03:10:59] <spulec> distribute==0.6.24 -> distribute==0.7.3

[03:11:14] <dstufft> ok, which pulled in setuptools 10.0.1

[03:11:17] <spulec> yes

[03:11:51] <dstufft> I wonder if the problem is related to distribute -> setuptools upgrade

[03:11:56] <dstufft> pip had some hacks to try to make that smoother

[03:12:04] <dstufft> but it's not the easiest thing to handle :/

[03:22:58] <jaraco> dstufft: why is pip running egg_info on the sdist? Shouldn't the egg-info already be present in the sdist?

[03:23:10] <jaraco> I guess it wouldn't be if it were a distutils-generated sdist

[03:23:43] <dstufft> jaraco: also because people put conditionals in their setup.py's to change what gets installed (like if WINDOWS: install_requires += ["windows thing"]

[03:23:50] <dstufft> so we want to regenerate it on the target platform

[03:25:47] <jaraco> I see --egg-base is specified. I need to learn more about that.

[03:26:15] <dstufft> jaraco: note: this code is way older than my involvement in packaging

[03:28:29] <jaraco> spulec, do you get the error when upgrading from setuptools > 1.0?

[03:30:33] <spulec> My original ticket was wrong. I never had setuptools explicitly installed, just distribute==0.6.24

[03:33:48] <jaraco> spulec: indeed. But what I'd like to know is if the issue occurs upgrading from, say, 9.1 to 10.0.1.

[03:35:02] <jaraco> If not, then I can assume the issue is specific to a distribute upgrade.

[03:35:53] <spulec> @jaraco I’m not sure how to see which version of setuptools distribute has installed (pip freeze doesn’t show setuptools)

[03:36:01] <dstufft> spulec: pip list

[03:36:46] <spulec> setuptools (0.6rc11)

[03:37:40] <spulec> interesting

[03:37:47] <spulec> I needed to upgrade pip to get pip list

[03:37:58] <spulec> and now I can install the new setuptools and the new distribute

[03:38:40] <dstufft> if you upgraded pip you're probably installing from wheels

[03:38:46] <dstufft> which don't execute etup.py at all

[03:38:54] <spulec> ah, good point

[03:39:34] <jaraco> If you force an install of setuptools 9.1, then run the same command Tom Scanlon did (to upgrade), does that succeed?

[03:44:56] <spulec> I upgraded to 9.1, but got the same error after that when trying to upgrade to 10.0.1

[09:58:52] <xafer> any idea what could cause: http://pastebin.com/8NJc4sNE

[10:00:34] <xafer> (that's the end of what I get when running pip install --upgrade setuptools -vvv)

[10:53:00] <xafer> seems like it is due to a setuptools-0.6c11-py2.6.egg in site-packages that doesnt get uninstall

[11:07:04] <xafer> I've an issue with setuptools update via pip: I've got an egg in venv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg but pip seems to search for an egg named setuptools-0.6rc11-py2.6.egg

[15:01:25] <__apr__> hi all

[15:01:26] <__apr__> I think I've found a bug

[15:01:26] <__apr__> when I install scapy-real==2.2.0-dev using pip 6.0.3, it works well, but then a pip freeze yields 2.2.0-dev0 as the installed version

[15:01:26] <__apr__> why is pip appending that 0 ? any way to prevent that?

[15:13:42] <xafer> __apr__, I guess you meant 2.2.0.dev0 instead of 2.2.0-dev0 ?

[15:16:55] <__apr__> xafer, sorry? didn't understand your point

[15:17:48] <__apr__> pypi doesn't have 2.2.0-dev0 -> https://pypi.python.org/pypi/scapy-real

[15:18:32] <xafer> 2.2.0-dev0 would be strange, 2.2.0.dev0 comes from pip implementing PEP440 for version specifiers

[15:19:02] <pmxbot> jaraco pushed 6 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:19:02] <pmxbot> Add test capturing requirement. Ref #320.

[15:19:02] <pmxbot> Restore _default_revctrl implementation (stubbed). Fixes #320.

[15:19:02] <pmxbot> Fix syntax on changelog

[15:19:02] <pmxbot> Bumped to 10.1 in preparation for next release.

[15:19:02] <pmxbot> Added tag 10.1 for changeset 26b00011ec65

[15:19:02] <pmxbot> Bumped to 10.2 in preparation for next release.

[15:19:52] <xafer> if you run your install with -v you'll be able to spot (among a lot of noise): "UserWarning: The version specified requires normalization, consider using '2.2.0.dev0' instead of '2.2.0-dev'."

[15:20:15] <__apr__> xafer, so... you're saying that this is an intended behaviour?

[15:22:00] <xafer> not sure :)

[15:23:04] <xafer> but pip install "scapy-real==2.2.0.dev0" seems to work

[15:23:17] <__apr__> yeah, was testing that in a virtualenv

[15:24:19] <__apr__> xafer, this is strange though, https://gist.github.com/andresriancho/d972b7f0769095737891

[15:24:34] <__apr__> in older versions it allows you to pip install scapy-real==2.2.0.dev0

[15:24:47] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:24:47] <pmxbot> Remove superfluous parentheses

[15:24:56] <__apr__> but it will show scapy-real==2.2.0-dev

[15:25:14] <__apr__> and in newer versions of pip

[15:25:23] <__apr__> it's the other way around, you install the one without the zero

[15:25:28] <__apr__> and get a zero appended

[15:25:31] <__apr__> crazy stuff

[15:26:00] <xafer> I think the goal is to promote the version specifier as defined by https://www.python.org/dev/peps/pep-0440/#public-version-identifiers

[15:28:34] <__apr__> xafer, do you know where I can find the code that does that translation?

[15:29:02] <xafer> https://github.com/pypa/packaging/blob/master/packaging/version.py

[15:30:09] <__apr__> cool, thanks, will take a look at that

[15:30:41] <xafer> you're welcome :)

[17:29:50] <pmxbot> jaraco pushed 8 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[17:29:50] <pmxbot> Remove unnecessary branch

[17:29:50] <pmxbot> Extract pattern and entry point parsing from EntryPoint.parse.

[17:29:50] <pmxbot> Correct implementation fixing failing tests

[17:29:50] <pmxbot> Use reduce to retrieve attributes. Reuse error from AttributeError when translating to ImportError.

[17:29:50] <pmxbot> Return value directly

[17:29:50] <pmxbot> Rename variable for clarity

[17:29:50] <pmxbot> Extract _load method which is the same as calling .load(False).

[17:29:50] <pmxbot> Don't allow imports relative to the pkg_resources module.

[17:40:44] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[17:40:44] <pmxbot> Use underlying invocation of ._load directly

[17:40:44] <pmxbot> Officially deprecated EntryPoint.load(require=False).

[19:50:38] <pmxbot> jaraco pushed 5 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[19:50:38] <pmxbot> Normalize indentation and whitespace

[19:50:38] <pmxbot> Use contextlib.closing on tarfile compat shim

[19:50:38] <pmxbot> Use simple context manager; don't bother deleting the variable.

[19:50:38] <pmxbot> Rewrite assert

[19:50:38] <pmxbot> Use pytest importorskip for skip logic

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 31st of December, 2014