Log file Viewer

[00:17:34] <dstufft> njs: you do science stuff right?

[02:42:12] <prometheanfire> ngoldbaum: well, gentoo doesn't come with it out of the box :P

[02:42:35] <prometheanfire> ngoldbaum: as I said earlier, our package manager checks with sha256/512 and whirlpool, so those would work too

[03:26:33] <njs> dstufft: I have a PhD -- in science!

[03:28:07] <njs> dstufft: or something like that

[03:28:10] <njs> dstufft: uh what's up?

[03:28:31] <njs> (unless you've gone to sleep, in which case I guess I'll see your reply tomorrow or something)

[08:57:14] <t4nk982> hey, quick question. I'm trying to bundle together a python library that in turn depends on two other libraries (Cython and meliae). the problem is that meliae requires Cython to be installed, so specifying both in install_requires doesn't really help.

[08:57:20] <t4nk982> is there a way to get around this?

[10:29:57] <ionelmc> t4nk982: what's the actual problem?

[10:51:44] <DRMacIver> dstufft: It's very possible this is me doing something wrong, but I was doing what seemed to me based on reading to be the best option. :-)

[10:53:00] <DRMacIver> dstufft: But basically I have https://github.com/HypothesisWorks/hypothesis-python/blob/master/setup.py#L51 and get a fairly constant (not high volume but enough that it's annoying) rate of "Hypothesis doesn't install correctly on 2.7" requests because people have old pip

[10:53:20] <mgedmin> environment markers :(

[10:53:35] <DRMacIver> mgedmin: what's the problem with environment markers?

[10:53:35] <mgedmin> it's not just old pip -- old setuptools can cause this too

[10:53:38] <mgedmin> or old wheel

[10:53:58] <DRMacIver> So is the conclusion that I just shouldn't be using environment markers if I'm shipping an sdist?

[10:54:06] <mgedmin> the problem is that they're not old enough to be supported by the versions of tools and libraries that everyone's sure to have :(

[10:54:19] <DRMacIver> Right

[10:54:33] <DRMacIver> Complaining about that on Twitter wasa basically the source of this :-)

[10:55:00] <DRMacIver> But basically I was under the impression that if I wanted *newer* pip to behave correctly I should be avoiding doing conditionals on Python version in setup.py

[10:55:37] <mgedmin> there was a range of new-ish pip versions that did Bad Things if you had the wheel cache enabled, and a setup.py did dynamic computations

[10:55:59] <mgedmin> but even newer pip versions made the wheel cache segregated by minor python version by default, to avoid this issue

[10:56:05] <DRMacIver> ok

[10:56:23] <mgedmin> I'd have to check the pip changelog to see what versions those were

[10:56:34] <mgedmin> hmm

[10:56:46] <DRMacIver> I guess basically my main question is: What is the actually correct thing for me to do here?

[10:56:58] <mgedmin> oh, and there's one way to be 100% compatible with everything!

[10:57:08] <mgedmin> which is: use dynamic checks in setup.py

[10:57:28] <mgedmin> but also specify install_requires using environment markers in setup.cfg, in the [bdist_wheel] section

[10:57:35] <DRMacIver> Ah, I see.

[10:57:37] <mgedmin> this means you duplicate information

[10:57:40] <DRMacIver> That's fine

[10:57:43] <DRMacIver> I'll do that. Thanks.

[10:57:49] <mgedmin> but I believe all versions of the tools work correctly in all cases

[10:58:12] <mgedmin> dstufft used to point me to an example on github, but I haven't bookmarked

[10:59:10] <dstufft> mgedmin: DRMacIver https://github.com/pypa/twine/blob/master/setup.cfg#L9-L15

[10:59:15] <dstufft> is the xample :]

[10:59:41] <DRMacIver> dstufft: I don't understand how this avoids this problem

[11:00:42] <DRMacIver> Oh, I see, your setup.py also does the check

[11:00:43] <DRMacIver> Right

[11:00:44] <DRMacIver> Thanks

[11:01:10] <mgedmin> oh, twine! of course

[11:01:37] <dstufft> DRMacIver: Oh, you pair it with uh, https://github.com/pypa/twine/blob/master/setup.py#L29-L32 or so, but basically ``pip install`` from a sdist will ingore that section of setup.cfg and just use what setup.py says, building a wheel though will use that section to override (compeltely, not in addition to) install_requires when the wheel is built, and every version of pip that has supported wheels supports markers inside of wheels

[11:01:58] <dstufft> DRMacIver: FWIW you could also just ship a wheel, that will probably cover most people who are complaining

[11:02:20] <dstufft> you have to go back to pip 1.4 to get a version of pip that doesn't support wheel by default

[11:03:02] <dstufft> Which is like, Ubuntu 12.04, but not 14.04, and Debian oldstable but not Debian stable

[11:03:27] <DRMacIver> dstufft: Thanks.

[11:03:34] <dstufft> (1.4 came out in 2013, 1.5 came out Jan 1st, 2014)

[11:03:56] <DRMacIver> BTW sorry if that came out a bit aggressively towards you/pip on Twitter. I was actually complaining about downstream packaging!

[11:05:00] <dstufft> DRMacIver: Oh no, not at all.I was just on my phone and twitter is a bit annoying :] I had an inkling it had something to do with that but wanted to make sure

[11:48:39] <ionelmc> dstufft: so basically there's no way to build a bad wheel with that setup.cfg technique?

[11:49:32] <ionelmc> does it break down if pip/wheel are old or something? (eg: incorrectly built wheel if pip/wheel too old)

[11:52:34] <t4nk982> ionelmc: http://bazaar.launchpad.net/~meliae-dev/meliae/trunk/view/head:/setup.py#L65 seems to be the problem. meliae requires Cython to be installed before it gets installed. so doing a simple "pip install Cython meliae" doesn't work, and the same things happens if I specify them both in install_requires of my own project.

[11:55:42] <mgedmin> meliae doesn't even use setuptools :/

[11:58:43] <t4nk982> apparently

[12:00:49] <ionelmc> t4nk982: looks like a broken setup.py to me

[12:01:03] <ionelmc> use something else or ask the maintainers to fix it

[13:21:32] <t4nk982> ionelmc: I was afraid of that. out of curiosity, how would this be fixed if it's using a function available in Cython?

[13:21:51] <t4nk982> isn't availability of Cython *needed* there?

[13:54:21] <tlyng> have something changed with pip/setuptools lately? Suddenly pip won't accept my requirements-dev.txt file, it raises RequirementParseError (Invalid requirement, parse error at "u'__placeh'"). It goes away if I removed the `extras` flags in requirements-dev.txt (./src/mypackage[test,experimental] => ./src/mypackage)

[14:02:23] <ionelmc> t4nk982: you can use it "lazily" - eg, have cython in setup_requires and then use the builtin support of cython from setuptools

[14:02:43] <ionelmc> t4nk982: though my preference is to just ship the C files and be done with it

[14:03:00] <ionelmc> i don't like projects that have cython in setup_requires - makes everything goddamn slow

[16:32:44] <puiterwijk> dstufft: hi. I'm seeing a lot of 500 errors on PyPI: on every package page after logging in, and when trying to register a new user

[16:49:32] <ronan> hi, is there an ETA on the next pip release?

[17:01:58] <xafer> A 8.1.2 should happen soonish hopefully

[18:35:21] <ronan> xafer: thanks

[18:36:13] <ronan> also, can pip's setuptools be updated? The current one is broken on pypy3

[18:36:39] <ngoldbaum> ronan: pip install -U setuptools?

[18:37:14] <ronan> ngoldbaum: no, I mean the one that pip vendors

[18:37:52] <ngoldbaum> ronan: you mean virtualenv? I don't think pip vendors setuptools...

[18:38:51] <ronan> ngoldbaum: I mean pkg_resources, actually

[18:43:54] <xafer> ronan: broken how ? is there an issue ?

[18:45:30] <ronan> xafer: https://github.com/pypa/setuptools/issues/487

[18:47:59] <ronan> and this causes pretty much every attempt to use pip to fail, e.g. http://paste.pound-python.org/show/h8z4MP1utqVfDPPKc4q7/

[18:48:25] <ngoldbaum> ah, pypy3

[18:50:13] <ronan> ngoldbaum: the 3.3 version should be released soonish

[18:57:45] <ionelmc> hmmm, keep getting 500 on pypi upload, what's going on?

[19:14:09] <agronholm> ionelmc: that happens from time to time; your upload itself should be fine

[19:14:13] <agronholm> please check

[19:16:30] <ionelmc> they are indeed there but it's annoying cause i'm trying to upload multiple dists :|

[19:16:44] <ionelmc> plus is slooooooow

[19:16:54] <agronholm> yup

[19:17:03] <agronholm> these problems have been going on for months

[19:19:10] <ionelmc> angry hulk mode soon

[19:19:20] <ionelmc> HULK PACKAGE!! ARGH!

[19:34:51] <dstufft> puiterwijk: still having problems? I was away

[19:35:18] <puiterwijk> dstufft: no idea. I'm sucked into spam fighting.

[19:35:30] <puiterwijk> I will check when I've won the current battle

[20:45:24] <prometheanfire> dstufft: is there a timeline or something for the new domain?

[21:25:42] <gsnedders> is there any way to programmatically ask "is this requirements file satisfied"?

[21:27:39] <gsnedders> Ah, on WorkingSet; WorkingSet.requires

[21:32:18] <gsnedders> Uh, how do I parse a requirements file in a way compatible with pip (i.e., supporting -r more-reqs.txt)?

[21:34:33] <[Tritium]> gsnedders: if you are writing a parser, you could look at how it is implemented in pip

[21:36:20] <gsnedders> [Tritium]: nah, I mean is there any API that does it? pkg_resources.parse_requirements doesn't seem to support -r :(

[21:36:31] <gsnedders> I'd rather avoid implementing it myself

[21:39:34] <tdsmith> do i remember correctly that pip treats anything in requirements.txt as a pip command line argument?

[21:39:55] <tdsmith> s/requirements.txt/a file passed to -r/

[21:40:23] <gsnedders> https://github.com/pypa/pip/blob/develop/pip/req/req_file.py appears to be the pip parse

[21:41:08] <gsnedders> tdsmith: so, uh, yeah

[21:43:23] <dstufft> prometheanfire: not specifically.but it's on my near term todo list

[21:43:34] <dstufft> gsnedders: there's no public API for it, but that's the private api

[21:44:43] <gsnedders> dstufft: yeah, I know pip doesn't have any public APIs, but relevant insofar as reference as to what pip does

[21:44:54] <prometheanfire> dstufft: thanks, just asking for a ping when it happens so we can test it