Log file Viewer
#pypa logs for Monday the 29th of December, 2014
[07:11:42] <ncoghlan> dstufft: sorry, I think I just broke your PR by renaming the file out from underneath you
[07:22:11] <ncoghlan> dstufft: yeah, git's rebasing heuristics are one of those cases where the guessing is good enough that it helps more often than it hinders :)
[07:36:21] <ncoghlan> dstufft: there's a reason I always run my Mercurial clones with history editing enabled :)
[07:36:54] <dstufft> ncoghlan: I try to avoid learning too much about Hg :/ I can't handle remembering too many things at once
[07:37:55] <ncoghlan> to be honest, the main difference between the two is the existence of prescriptive workflows
[07:38:21] <ncoghlan> learning just-enough-git to work with the PR model or the Gerrit review model is pretty easy
[07:38:38] <dstufft> I don't really mean difference in abilities, just difference in what things I need to type to make a thing do a thing
[07:38:48] <dstufft> that's mostly why my branch workflow for hg involves hg diff and the patch command
[07:38:56] <ncoghlan> so all the complexity that's there to support the Linux kernel model can be ignored
[07:40:03] <ncoghlan> that's what I mean though, hg lacks a similarly simple and prescriptive "this is a really good local workflow" model
[07:41:42] <ncoghlan> at some point, Pierre-Yves and I will get the cpydev extension up to a release ready state
[07:42:00] <ncoghlan> and we'll hopefully have something pretty clean that works well for local CPython development
[07:43:01] <dstufft> that'd be nice, I probably won't personally use it, but better tooling is always good
[14:19:39] <apollo13> dstufft: when running pip install psycopg2 I no longer get any output till it's finished
[14:19:53] <apollo13> ie I get Running setup.py install for psycopg2 and when it is finished a dump of:
[14:25:20] <dstufft> apollo13: um, well I don't think we changed anything that would cause the calls to gcc to get buffered, other than we reduced the amount of output in general so maybe python's built in buffering is taking effect
[14:26:27] <dstufft> that might have something to do with it too... though I don't think that does any buffering
[14:27:51] <dstufft> apollo13: to be clear, the problem is that the output is coming all at once at the end, instead of there's just less output right?
[14:28:48] <agronholm> does anyone know why the <, >, <= and >= operators are missing from pkg_resources? those operators are specified in PEP 426.
[14:29:07] <agronholm> if they weren't missing, I wouldn't have to keep using [metadata] in setup.cfg
[14:33:39] <agronholm> I read in the wheel documentation that requires-dist in [metadata] is deprecated and setup.py's extras_require should be used instead
[14:35:25] <xafer> agronholm, did you test with extras_require={":python_version < '3.2'": 'futures'} ?
[14:40:36] <dstufft> markers aren't really entirely fully supported yet I don't think, PEP 345 is kind of half way supported, and PEP 426 isn't complete yet
[14:41:47] <xafer> on a project of mine I have: {':python_version == "2.6" or python_version == "2.7"': ['mock>=1.0.1'],}
[18:16:21] <mattupstate> might someone be able to point me to a working (open source project) example of using `dependency_links` for a package on github? No matter what I've tried I can't seem to get it to work
[18:29:35] <mattupstate> wondering, does pip/setuptools download the package(s) from the dependency_link value before seeing if the dependencies can be fulfilled?
[19:05:06] <sontek> Hey, I haven't been following the version changes in pip 6, what changed that makes something like this not work: "smlib.globaltemplates<2.0.0,<=1.0.2,>=1.0.7"
[19:05:48] <sontek> A bunch of people within the company have started reporting that our software no longer works when they are spinning up new versions and its all because pip 6 is being pulled in
[19:06:08] <sontek> So wondering what I need to tell people, is what they are doing fixable or do I just have them pin to 1.5.6?
[19:06:39] <dstufft> sontek: setuptools 8+ and pip 6+ implement PEP 440 which changes the meaning of , in a version specifier from "a bunch of complex rules that nobody really fully understands and are really hard to explain" to "it means AND"
[19:07:09] <dstufft> so in particular, there is no possible version which is <2.0.0 AND <=1.0.2 AND >=1.0.7
[19:09:15] <sontek> Ok, is there a way for them to allow less than or equal to 1.0.2 or >= to 1.0.7 and less than 2.0.0 now?
[19:09:28] <sontek> Basically their problem is there is a range of versions that are broken, they want to prevent those
[19:10:49] <dstufft> sontek: there is no support for OR at the moment, your best bet is to use a series of != for the broken versions
[19:34:16] <JakePee> Having an issue installing the distribute package through pip, getting this https://dpaste.de/EEDg
[20:33:13] <glyph> Is there a document explaining best practices for what a random Python project should tell its users to do to install it?
[20:35:06] <dstufft> glyph: Hmm, I don't think we have any documentation on how a random python project should tell users to install it, certainly the goal is to get as close as possible to the answer is just ``pip install foo``. Probably that would be a reasonable topic for https://packaging.python.org/en/latest/distributing.html
[20:35:43] <glyph> dstufft: If you tell people to "pip install" stuff with native dependencies (particularly: libssl, libcrypto, libffi) then just 'pip' gets you into trouble
[20:36:13] <dstufft> We also have https://packaging.python.org/en/latest/installing.html, but that doesn't really touch on any of the harder issues like native dependencies on platforms where they can't just be ``pip installed``
[20:36:18] <glyph> dstufft: mostly I've been wondering how to do this for Twisted without including a nonfiction novella about the development of dynamic linking on unix platforms
[20:37:44] <dstufft> yea, I don't think we have a super great answer for making it easy on non Windows (ironically, given the sordid history of Windows and compiled things)
[20:39:20] <apollo13> ironically enough the platform where building is the easiest is the hardest to support
[20:39:39] <dstufft> glyph: there was a big long discussion on a pip bug and then some uh, science users did some tests and it worked good enough we turned it on
[20:40:20] <dstufft> glyph: https://github.com/pypa/pip/blob/develop/CHANGES.txt#L282 I'm not sure if we actually made a formal announcement beyond that
[20:40:47] <glyph> Do I have to have a snow leopard VM to build for older OS versions, or will yosemite do the right thing?
[20:40:47] <dstufft> apollo13: I would argue that the fact building is easy probably has something to do with the fact that distributing pre-compiled is harder
[20:41:24] <dstufft> glyph: in pip 1.5 the SDK version was matched with an ==, in pip 6 the SDK version is matched with a >=
[20:42:10] <dstufft> so homebrew Python (or pyenv) uses the 10.10 SDK, so it won't work on system Python or PYthon.org installer python
[20:42:46] <dstufft> glyph: or use python.org Python to build wheels, they set the SDK to like 10.6 or something
[20:45:36] <glyph> dstufft: I mean, that makes sense, they build the OS in a self-hosted way, it's not like they build all the included frameworks for use on older OSes
[20:46:55] <dstufft> if you build a wheel with python.org python it'll be acceptable to pip 1.5.x on python.org python and will be acceptable to most OSX pythons with pip 6+ unless they are compiled with an older SDK than what python.org installs with
[20:50:31] <dstufft> obviously modulo dynamic linking (probably want to staticlly link wheels unless you're really sure users aren't going to end up with a new/old/strange version of it via homebrew or something
[20:51:53] <dstufft> glyph: I think the next major improvement int his area is going to be expanding the Wheel spec so it can include distro + version in the filename, and setup PyPI so it allows both generic linux wheels, and distro specific wheels, and at that point it's up to the projects themselves to publish wheels that work
[20:56:39] <dstufft> glyph: I actually don't know if cryptography _can_ ship OSX wheels without static compiling openssl, does the OSX SDK version include openssl?
[21:04:37] <dstufft> glyph: can you open a ticket on https://github.com/pypa/python-packaging-user-guide about offering guidance for telling people how to tell their users to install their things
[21:18:26] <glyph> dstufft: btw, that changelog entry is for pip; when did PyPI start allowing OS X uploads?