Log file Viewer
#pypa logs for Thursday the 12th of November, 2015
[16:00:17] <mitsuhiko> eg: we want to use this specific version of the package, but want to consider upgrading to something api compatible
[16:06:52] <xafer> I think you are looking for https://www.python.org/dev/peps/pep-0440/#compatible-release i.e. `~=2.0` for the 2.0 series
[18:01:59] <dstufft> remember when you couldn't make a validated TLS connection to PyPI and neither pip nor easy_install validated TLS anyways evne if you tried
[18:02:10] <dstufft> that was pretty cool how we all used to just randomly execute crap downloaded via http
[18:03:10] <tdsmith> it's amazing how un-burninated the universe is vs how burninated it totally could be
[18:04:23] <dstufft> tdsmith: It terrifies me that I know of several multi million dollar companies that ``pip install`` directly from PyPI in their production infra
[18:04:57] <tos9> dstufft: hooray! we're not one of them anymore. Although we might become one again, I will probably fling devpi out a window very soon.
[18:08:02] <dstufft> mitsuhiko: xafer is right about ~=, though that's only pip 6+ and setuptools 8+ so just ftr
[18:08:06] <tos9> this appears to partially solve the non-addressable-per-package-index thing I've complained about.
[18:08:52] <dstufft> you still can't do that, but you can make it an error if it doesn't match the hash at least
[18:09:36] <dstufft> whenever I get around to reworking our multiple repo support the rest of that will get taken care of
[18:25:34] <kober> What does this mean setuptools must be installed to install from a source distribution
[18:26:51] <jaraco> kober: It sounds like you have a pure-pip installation (without setuptools), and you’re trying to install a package that’s not a wheel, so pip requires setuptools to be installed to build the wheel for installation.
[20:17:29] <jaraco> mitsuhiko: two ways I use. (1) Use setuptools_scm and commit the files to the SCM repository or (2) use MANIFEST.in.
[20:17:59] <mitsuhiko> that's not really what i'm after but i found a solution for my issue anyways at this point
[20:19:07] <mitsuhiko> it involves fetching a finalized sdist command and extending the file list after copying files manually over to the build folder
[20:19:51] <jaraco> I missed the distinction, but now I understand. Glad you found something that worked.
[20:44:29] <dstufft> https://github.com/jaraco/setuptools/blob/master/setuptools/command/develop.py#L116-L117
[20:45:57] <dstufft> mitsuhiko: is it actually not running build_ext, or is build_ext not doing anything?
[20:46:32] <mitsuhiko> as this is the only path that seems to be invoked inplace and not for all builds
[20:49:07] <dstufft> mitsuhiko: I don't see you overriding build_ext at all here, it looks like you've overridden just plain old build?
[21:32:00] <dstufft> mitsuhiko: for whatever it's worth, it's very likely that in the nearish future pip will support pluggable build systems
[21:32:46] <dstufft> so in the nearish future it's very likely you'll be able to not use setuptools/distutils at all :D (of course with the caveat that you'll need a setup.py shim if you want to support older pips)
[21:34:11] <tos9> what are the chances in the nearish future that there will be a non-pip wheel installer that I should / can use
[21:35:16] <dstufft> probably not likely, but I'm confused why you don't want pip but you're OK with some other thing being installed
[21:35:24] <tos9> apollo13: the difference would be $other_tool would be small and focused, but $other_tool doesn't even *need* to be installed on the server
[21:37:00] <dstufft> mitsuhiko: tos9 Note: That won't do everything. Right now it'll get you most of the way there but you won't get script wrappers. In the future it's likely we'll add post-install hooks as well which you won't get with that either
[21:37:39] <dstufft> tos9: fwiw pip works zipped up if you have a OS bundle for SSL certiificates or you aren't using ssl
[21:38:12] <dstufft> if you don't want to install pip, you just want to have a executable file you can scp around execute, and delete
[21:38:41] <tos9> dstufft: I think my overall problem with pip right now is I don't know yet how to treat it
[21:39:08] <tos9> but yesterday $coworker asked me "what's our protocol for managing pip versions in our infra, is that via config management or manual"
[21:39:38] <dstufft> it *should* be focused on developers and we *should* be using pex or some other thing to make single file deployments
[21:39:50] <tos9> because ultimately I *do* want to pin a minimum version, but pip is an oddball -- most of the time I want latest, because older pips stop to work occasionally, but latest is obviously dangerous for other reasons
[21:39:53] <dstufft> but none of those stories are as fully baked as pip is, so pip gets all over the place
[21:40:51] <dstufft> I haven't actually used pex, but I hear it works pretty OK if you have a fairly homogenious environment and can ensure Python is installed
[21:41:27] <tos9> I haven't either, and I'm sure I'd be into some fun if I tried it, not sure how many people out there are using pex with pypy.
[21:42:20] <dstufft> I think the things that pex does should be mostly drop in for PyPy... but PyPy might not be used by anyone else who is using pex so there's a good chance for weirdo edge cases
[21:44:24] <dstufft> at the end of the day, pex is really just a zip file with a __main__ that has some special handling for C extensions and other things that aren't zipimport safe
[21:54:39] <tos9> dstufft: for running latest I'm less worried about it being pip's fault and more that when something is broken it will have to be a thing I remember to check.
[21:55:15] <mitsuhiko> and that one was the only one that actually worked because you can fuck around with binaries so that they locate resources relatively
[21:55:54] <mitsuhiko> https://github.com/mitsuhiko/lektor/blob/master/gui/bin/make-python-framework-relocatable <- install_name_tool ftw
[21:57:07] <mitsuhiko> it's frustrating because all the tools we have just make it worse rather than easier
[21:57:41] <mitsuhiko> we just try to force everything into some bizarro unix world that exists nowhere
[22:05:59] <jaraco> I remember my first PyCon (2008), I was surprised to see so few Windows users. My sense is that because Python is dominated by Unix users, it tends to be Unix first and Windows as an afterthought and only by volunteers. The Windows support then becomes marginalized, creating an unfortunate feedback loop.
[22:06:34] <jaraco> Some champions in the Windows world have gone a long way to alleviating that pain, but it’s always there.
[22:16:10] <jaraco> But for me, as a primarily Windows user, Python was a very attractive language for how it bridges the platforms without hiding them (like the JVM does).