Log file Viewer
#pypa-dev logs for Thursday the 18th of December, 2014
[00:23:32] <herrwolfe> silly question - does passing '--no-wheel-install' guarantee that the package will not be installed using a wheel?
[00:23:57] <herrwolfe> I'm trying to workout a test case and am being confounded by an error not being raised
[08:05:28] <msabramo1> @dstufft: #2221 is #2207 (display versions of installed packages) but without the `project==version` format
[13:40:17] <pmxbot> jaraco pushed 7 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:41:37] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[14:09:25] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[14:17:02] <jaraco> dstufft, I've released your three PRs as 8.1 (mainly because of the added classes). Since 'packaging' support is stabilizing and unlikely to be backed out, I've also released 8.2 with the pending changes in master.
[14:17:51] <dstufft> python -W ignore::PEP440Warning and python -W ignore::pkg_resources.PEP440Warning doesn't seem to work
[14:18:30] <dstufft> of course python -W ignore::RuntimeWarning works, since it's a sublcass, and PEP440Warning works when called programatically
[14:25:32] <dstufft> jaraco: I think we can say that setuptools has probably stabilized now? I had folks stop submitting PRs places to update their version of setuptools (like Homebrew etc) until we got it stablized
[14:26:32] <jaraco> dstufft, I would hope so, but given that we _just_ made a release, I'd give it a couple of days more.
[14:57:52] <herrwolfe> dstufft: I'm a little confused by pip.req.req_set.Requirement.prepare_files and am wondering if I might be missing something - is there a functional reason why a pkg_resources.Distribution object is only created for wheels installs?
[15:00:33] <msabramo1> thoughts on https://bitbucket.org/pypa/pypi/pull-request/60/fix-bb-214-make-rst-rendering-not-fail-for/diff ?
[15:00:47] <herrwolfe> xafer: awesome, I'll take a look at this, I was kind of feeling around and trying to do that myself
[15:02:01] <herrwolfe> xafer: but, I think I was getting a bit bogged down in some of the test failures that were caused by what I was trying to accomplish
[15:02:10] <dstufft> msabramo1: I think I might just modify pypi to use readme already instead of waiting for warehouse to start using that
[15:04:08] <xafer> herrwolfe, yup, parse_editable was putting dict inside req_to_install.extras which dist.requires doesnt like (therefore the first commit of the PR)
[15:04:37] <msabramo1> I had been thinking it would be nice for pypi to use readme but I didn't know if richardjones was up for a biggish change like that
[15:06:01] <sigmavirus24> I think PyPI is mostly in maintenance mode (from discussions I've had with Richard)
[15:06:35] <dstufft> switching to readme would bring the benefit that people can test their readme's against whatever PyPI is going to use to render it
[15:06:48] <msabramo1> I think in my head I imagine r1chardj0n3s thinking of PyPI like a particular legacy system that I maintain at work, which I try to minimize spending time on :)
[15:08:29] <msabramo1> distutils has `python setup.py check —restructuredtext` I discovered recently, but it's broken :-(
[15:08:42] <dstufft> I was planning on jsut rolling it out in warehouse, but then things happened and warehouse took longer then intended
[15:09:59] <msabramo1> let's make PyPI use readme and then piece by piece replace bits of PyPI with warehouse :)
[15:16:06] <dstufft> not sure, we're going to try to release faster than we have in the past, but unless we make backwards compat changes we'll release it as 6.Y
[15:16:51] <xafer> I was thinking of all the RemovedInPip7Warning and the code that could be removed with them :)
[15:17:18] <dstufft> yea that stuff, probably we'd want to wait at least 6 months before releasing 7
[15:27:55] <msabramo1> dstufft: Maybe we should merge something like https://bitbucket.org/pypa/pypi/pull-request/58/add-tests-test_description_utilspy/diff before changing PyPI to use pypa/readme?
[16:41:05] <xafer> dstufft, did you have time to rethink the logger issue of https://github.com/pypa/pip/pull/2153 ?
[17:00:30] <dstufft> jaraco: I've got someone arguing that the PEP 440 warning is going to confuse end users and I wanted to get your opinion here, I see two possible situations -> a) An End user is doing something, gets the warning and it helps them solve a problem because the failure condition without it isn't the greatest and b) The end user isn't doing anything, might not even know python is involved and things are working fine but they get a warning that
[17:01:07] <dstufft> Do you think we should silence the warning by default, and make it possible for people to re-enable it using Python's warning control
[17:01:47] <jaraco> I imagine https://bitbucket.org/pypa/setuptools/issue/306/setuptools-82-spews-end-user-error is also relevant to that discussion.
[17:03:12] <jaraco> I imagine that (b) is pretty substantial, especially if system packages typically get non-PEP440 version numbers.
[17:03:29] <dstufft> I don't entirely agree that option (A) isn't signifcant, for instance I've seen an issue where it was useful already, but I don't know if (b) is more signifcant or not
[17:03:50] <dstufft> in particular devstack only gets this because they force upgrade to the latest setuptools intoo the system python, and not for instance in a virtualenv or anything
[17:03:52] <jaraco> It's a lot like the DeprecationWarning debate which eventually settled on disabling it by default, but having certain tooling enable it (unittests).
[17:12:48] <dstufft> jaraco: I'm thinking maybe we should have the setup() function turn it back on?
[17:14:23] <jaraco> dstufft, That sounds exactly right, and consistent with what sdague has recommended (on during install/removal).
[17:19:30] <dstufft> jaraco: so there's actually another warning already that happens during setup.py execution if the version passed to setup.py isn't kosher, do we still want to do anything but silence PEP440Warning by default? The big difference will be that if we just silence PEP440Warning by default, and someone does ``setup.py install`` on a thing whose version is fine, but there is something it depends on already installed with a wierd version you won't
[17:19:31] <dstufft> get a warning about that other thing, but if we turn on PEP440Warning during install you will
[17:21:46] <jaraco> dstufft: I'm not sure. I'm starting to think the warning should only happen during a build step.
[17:23:34] <dstufft> jaraco: I think I have it, I'll just turn this particular noisy warning off by default (because it happens in pkg_resources, and pkg_resources gets used for lots of stuff), and I'll turn it back on inside of pip
[17:24:07] <dstufft> that'll probably get good enough coverage of the warning for people to fix things, without spamming end users
[17:24:12] <jaraco> That seems reasonable. Maybe it should be equivalently enabled during easy_install.
[17:32:51] <dstufft> jaraco: also let me just say, thank you again for accepting PRs on github, it's like 1000x easier for me :D
[17:33:09] <dstufft> jaraco: and I do have a TODO item still to figure out what all needs done to make github.com/pypa/setuptools happen ;)
[17:35:00] <jaraco> My pleasure. I do feel a bit of sadness that Mercurial is losing mindshare in the Python community, but that's just the way it is.
[17:45:25] <sigmavirus24> I was one of those kids thought they'd be a kernel hacker when they grew up so I learned git first
[18:02:30] <sigmavirus24> dstufft: stupid question: with entry_points, what are extras meant to be and how are they declared?
[18:03:17] <sigmavirus24> okay so they can't describe something on the entry point itself, like metadata
[18:23:59] <dstufft> jaraco: do you have an estimated time for when you plan on merging https://github.com/jaraco/setuptools/pull/23 and cutting a release? I ask only to plan my day better ;)
[19:24:46] <msabramo1> @dstufft, @pf_moore: See https://github.com/pypa/pip/pull/2219 and https://github.com/pypa/pip/pull/2221 when you get a chance
[19:58:29] <qwcode> to be clear, it will log stuff like this, right: Sphinx 1.2.3 (<path>/lib/python2.7/site-packages)
[20:00:54] <pf_moore> I'm not so sure about 2221 (the install one) - as qwcode said, the inconsistency bothers me (the format is different as well, "Sphinx-1.2.3" if I'm reading the code properly
[20:18:55] <pf_moore> I've just noticed that 2219 (the uninstall one) relies on the string representation of a dist. I'd rather the format was explicit. Proper comments inline, but I'm holding off on merging for now.
[22:00:01] <msabramo1> I would love for https://bitbucket.org/pypa/pypi/pull-request/58/add-tests-test_description_utilspy/diff to land at some point, it will help with my WIP to make PyPI use pypa/readme
[23:08:58] <dstufft> tomprince: can you expand on what command you're running and what the error is?
[23:12:20] <dstufft> tomprince: does it work if you do pip install --no-index --find-links . apache_libcloud==0.16.0+clusterhq.0
[23:27:24] <dstufft> tomprince: ok I see, it doesn't seem to be able to parse it out of a wheel file, it can parse it out of a .tar.gz
[23:36:06] <msabramo> dstufft: Yes. If you look at https://bitbucket.org/pypa/pypi/pull-request/58/add-tests-test_description_utilspy/diff, you'll see that PyPI generates HTML for span, pre, and a