Log file Viewer
#pypa-dev logs for Wednesday the 25th of February, 2015
[10:12:36] <xafer> hello, could someone grab my PR: https://github.com/pypa/pip/pull/2451 and run "tox -e py27 tests/functional/test_uninstall.py -- -k test_uninstall_setuptools_develop_install" to give me a clue of what is happening ? test runs ok on my machine but not on travis :'(
[13:07:23] <xafer> cf https://github.com/xavfernandez/pip/commit/bc8c68e7195abba708a635925115bac3c0d70a4f I was running python some_path/setup.py without changing the current directory, meaning the egg-info were produced in the same dir I was making the pip list
[13:30:59] <pf_moore> Thinking about script wrappers. If we're looking to standardise wrappers and put them into packaging, what's the actual point?
[13:31:47] <pf_moore> Seems to me we could end up just having 3 implementations rather than 2, not much of an improvement...
[13:34:11] <dstufft> I'm less concerned with everyone using the same implementation and more about there being a defination of what a script wrapper is supposed to support and such. Obviously it'd be nice if we all used the same implementation since I don't think this is the kind of code that anyone really wants to write :). I'm also not sure if it really needs a PEP or not. A good first step might be to just file a ticket on pypa/packaging and ping nick to see
[13:35:48] <pf_moore> Cool. Personally, I have 2 goals - first distlib's a big dependency just for the script stuff, but secondly (the hard one) I'd prefer it if pip and setuptools used the same implementation.
[13:36:14] <pf_moore> It's a pain when people have bugs that say X works when I install from wheel but not from sdist (or conversely).
[13:36:48] <pf_moore> Not sure how jaraco would react to that, though, and whether he'd be OK with an external dependency (I don't think setuptools vendors stuff ATM)
[13:36:54] <dstufft> yea I have both those goals too, though I also think we might be able to get setuptools to just use our our implementation (whatever that is) whenever we're installing from sdists
[13:37:29] <dstufft> one thing that would be different between pip and setuptools I think, is that our wrapper don't depend on pkg_resources, but setuptools' does
[13:37:41] <dstufft> and I'm not sure there's a way to get setuptools' wrappers to not depend on pkg_resources
[13:38:27] <dstufft> (that's because setuptools does the multi version install thing which we disable, and it needs pkg_resources to activate the right version)
[13:38:42] <pf_moore> Yeah, that'd still be a sticking point. But maybe it's doable by hacking setup.py to provide a different template (like we already inject setuptools)
[13:39:18] <pf_moore> The 2 key things I want are (1) no more py file, just an exe with embedded py, and (2) no runtime pkg_resources dependency
[13:41:11] <dstufft> I just know uh, what's his face (god damnit, my mind is blanking, the MS guy doing the new installers) mentioned that
[13:41:46] <pf_moore> Hmm, I can't think I care about that, but I don't really know the implications.
[13:43:16] <dstufft> updating pip itself, we could be smarter about not needing/trying to replace the script wrapper, but it's more likely we'd want to replace the py file than replace the .exe file
[13:43:34] <dstufft> but again, not sure that telling people to use ``python -m pip `` to upgrade pip is that big of a deal with
[13:44:11] <dstufft> to be clear, in general my preference would be for embedding just because single file is simpler on end users than two files. Just want to make sure we're not going to prevent ourselves from doing something else we'd want to do
[13:44:54] <pf_moore> Yeah. But, we've been using single file wrappers for wheel installs since they started, and no issues so far.
[13:46:39] <dstufft> I'd still probably suggest making sure the signing implications aren't going to bite us, but in general +1
[13:47:11] <pf_moore> Also, I think tacking a wrapper on the front of some code is the way things are going on Windows. You can tack a launcher on a pyz archive for a full single-file app.
[13:48:20] <pf_moore> The PEP doesn't mention adding exe wrappers. That's just something 3rd parties (Vinay, in his pyzzer app, and me :-)) are doing at the moment
[13:50:49] <pf_moore> I'll speak to Steve about the signing issue. And I'll raise an issue on packaging and ping Nick.
[13:52:08] <dstufft> I feel the script wrappers are something that all the packaging tools need, so in that vein it's something that makes sense in packaging
[13:52:27] <pf_moore> Yeah. One thought though. It'd be very easy for packaging to turn into just another big bunch of useful stuff, much like distlib and setuptools before.
[13:52:56] <pf_moore> I like the idea that packaging is "standardised stuff", but like you say it's hard to define that precisely in a PEP
[13:53:57] <pf_moore> Worth noting though that PEP 459 (metadata extensions) defines an "export spec" which is essentially an entry point, and states (vaguely) that wrapping them in scripts is something installers should do
[13:54:45] <pf_moore> It's hard to say too much more before you're just writing a spec for part of the packaging project. It's not as if you can say "all 3rd party implementations must do X, Y, Z"...
[13:57:15] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:57:15] <pmxbot> Only require rst.linker when docs commands are invoked. Also specify sphinx dependency.
[13:57:15] <pmxbot> Update conditional setup-time dependency to also support pytest and test commands.
[13:57:15] <pmxbot> Move pytest config to pytest.ini (as it conflicts with the pytest-runner pytest command).
[13:57:21] <dstufft> pf_moore: I was vaguely originally planning on just including script wrappers when we standardized the entry point itself
[13:58:10] <dstufft> (not every single line of code in packaging needs to be PEP backed, like it has LegacyVersion to deal with non PEP 440 compliant versions)
[14:01:34] <pf_moore> dstufft: Yeah. It's not like there's a huge rush to change this stuff, though. Just on my mind at the moment with the 2 current PEPs I'm doing...
[14:02:16] <dstufft> I mean I'd like to ditch distlib, it's one of the things keeping us from being able to operate without the ssl module
[14:04:06] <pf_moore> I didn't know that. I'd only been looking at ditching it because it's a big dependency to pull in for a couple of relatively small uses.
[23:45:50] <r1chardj0n3s> because I was looking at the code again I got to remove the bit I vendored pre "1.6"
[23:51:29] <dstufft> except for the fact I can't remember anything except stupid trivia like what version something happened in