Log file Viewer

[03:55:01] <_habnabit> arggghhhh

[03:55:30] <_habnabit> now it looks like pip is ignoring my --build directory? InstallRequirement.build_location seems to think it can just mkdtemp anywhere and it'll be ok

[08:25:35] <tomprince> ronny: Have you seen the work that lifeless has done in pip, for handling setup_requires in pip?

[08:28:01] <ronny> tomprince: not really, but what i have in mind would probably makes his stuff a lot more simple

[08:28:54] <tomprince> Well, it has already landed (but hasn't been released).

[08:29:05] <tomprince> It reads setup_requires from setup.cfg

[08:29:41] <ronny> tomprince: ah, that, but does that work with normal setup.py?

[08:30:30] <tomprince> No.

[08:33:34] <ronny> tomprince: then its completely orthoginal to what i have in mind ^^

[08:56:43] <nanonyme> dstufft, cool. Mainly I'm going to build a version of certifi that uses wincertstore to make pip use system certificates

[08:57:17] <nanonyme> dstufft, don't yet have an idea of how to do it for Linux

[09:23:38] <nanonyme> Is there such a concept as platform-dependent requirements?

[09:25:42] <ronny> nanonyme: yes

[09:25:56] <ronny> nanonyme: extras can have environment markers

[09:26:49] <nanonyme> ronny, will it automatically pull it on that platform if I do pip install foo then?

[09:27:28] <ronny> nanonyme: yes

[09:27:43] <ronny> even if you use wheels

[09:36:38] <nanonyme> ronny, cool, I'll fix it that way soon then

[09:36:42] <nanonyme> Just getting it out first

[09:41:32] <nanonyme> ronny, https://github.com/nanonyme/syscertifi/blob/master/setup.py probably got it wrong

[09:42:07] <ronny> nanonyme: completely wrong, thats a named extra, not a environment marker dependent extra

[09:42:38] <ronny> the extra name should be something like ':sys_platform == "win32"' i think, please check out the docs on environment markers

[10:44:13] <nanonyme> ronny, can't find anything like that in Google nor in docs

[10:44:36] <nanonyme> Nor in setuptools docs internal search

[10:50:55] <ronny> nanonyme: docs suck a bit, see https://bitbucket.org/pytest-dev/pytest/pull-request/269/add-support-for-building-proper-wheels/diff for examples

[10:52:21] <nanonyme> Oh, there's a PEP

[10:55:30] <nanonyme> Got it

[10:56:01] <nanonyme> So like this https://github.com/nanonyme/syscertifi/blob/master/setup.py

[10:56:47] <nanonyme> Could I also split https://github.com/nanonyme/syscertifi/blob/master/certifi.py by environment markers so that I can define the two functions in different files, one for Windows and one for others?

[10:57:27] <ronny> nanonyme: nope

[10:57:36] <nanonyme> Okay

[10:57:47] <nanonyme> Well, this is already good enough for a lot of things

[10:58:41] <ronny> nanonyme: you could make platform dependent wheels shippping minimal scripts

[10:58:53] <nanonyme> Right

[10:59:31] <ronny> nanonyme: or a package, and use entrypoints for platform names, just telling the right files

[11:00:05] <ronny> nanonyme: but practically, the version as is is fine

[11:00:07] <nanonyme> I'll think about that later. There was just demand for this for Windows on #python so ended up writing it

[11:01:11] <nanonyme> On other platforms using OpenSSL PEM is probably just fine

[11:01:34] <ronny> hmm, openssl needs removal from the world tho ^^

[11:03:41] <nanonyme> Blame Python core developers for calling the context variable openssl_cafile instead of system_cafile

[11:03:56] <nanonyme> Now we're stuck with it forever even if OpenSSL is removed

[11:05:06] <dstufft> nanonyme: pip already uses the system certificate store on *nix (assuming it's in one of the "standard" locations for those files

[11:05:27] <mgedmin> nanonyme, why platform.system() == 'Windows' rather than sys.platform == 'win32'?

[11:05:48] <nanonyme> mgedmin, just a habit. No special reason

[11:06:12] <nanonyme> dstufft, yeah, but it makes sense to do the same on Windows too through

[11:07:11] <nanonyme> s/rough/though/

[11:07:52] <nanonyme> dstufft, there was just yesterday someone complaining on #python how they couldn't get pip to read certs from certificate store on Windows. syscertifi is a platform-independent solution for this

[11:08:47] <nanonyme> (very little original code, just combining what already exists)

[12:29:30] <Sublime_> is there a way with pip to download a package source but not install it ?

[12:30:05] <tos9> Sublime_: pip install --download . twisted

[12:30:06] <ronny> Sublime_: pip install --download will

[12:30:26] <Sublime_> where will it put it by default ?

[12:30:54] <Sublime_> nvm just read the doc for --download

[12:38:42] <Sublime_> thx guys !

[12:51:36] <Sublime_> how about finding a packages dependencies ?

[13:04:33] <ronny> Sublime_: download also downloads the dependencies

[13:06:00] <Sublime_> what I mean is: is there a way without downloading anything to know what dependencies a certain package has

[13:13:50] <ronny> Sublime_: if it has a egg info folder, take a look at the requires.txt or so (i dont recall the exact name)

[13:14:19] <DanielHolth> wheels are designed so that you can do a partial request for the last few kb of a wheel, and you will get the metadata

[13:14:32] <DanielHolth> depending on the size of the zip directory of course

[13:15:04] <DanielHolth> Then I realized almost all Python packages are pretty small.

[13:17:42] <Sublime_> ronny, thanks

[15:51:45] <ztane> which way should I use to get both maintainer and author properly in PKG_INFO from setup(); if I have maintainer and author, the maintainer becomes the author in PKG_INFO if I use setup from setuptools

[15:53:19] <ztane> even setuptools 15.1

[15:53:42] <ztane> yet pypi has maintainer and author separately

[15:54:34] <_habnabit> tomprince, for compatibility, would you have to declare your setup_requires in setup.py and setup.cfg both?

[16:02:11] <_habnabit> ok so i'm still having trouble getting everything to play nicely with everything else. i'm trying to run gcov over my C code, and afaict gcov /requires/ that the .c files exist in the same place that they existed when you ran the C compiler over them. i'm using tox to install my package, and the end result seems to be that even with `pip install --no-clean --build ...` the directory where the .c files were

[16:02:11] <_habnabit> built is being put in /tmp and getting deleted. does anyone have any idea how to solve this?

[16:09:47] <ionelmc> _habnabit: for coverage measurements you have two options: develop mode (usedevelop=true in tox.ini i think) or having path aliases in coveragerc

[16:10:20] <_habnabit> ionelmc, this is gcov, not coverage.py

[16:11:01] <ionelmc> _habnabit: stuff like this seems to work https://github.com/ionelmc/python-lazy-object-proxy/blob/master/tox.ini#L165-L174

[16:11:40] <_habnabit> ionelmc, py.test knows about gcov?

[16:11:40] <ionelmc> _habnabit: eg, you can see here the C ext being measured https://coveralls.io/builds/2315712

[16:11:51] <ionelmc> i have an env that merges the C coverage

[16:12:16] <ionelmc> _habnabit: https://github.com/ionelmc/python-lazy-object-proxy/blob/master/tox.ini#L86-L91

[16:13:33] <ionelmc> _habnabit: so that cpp-coveralls does whatever magic is needed to collect the C coverage

[16:13:57] <ionelmc> not sure what non-coveralls reporting solutions are there

[16:14:05] <ionelmc> coveralls is nice, give it a shot

[16:14:10] <_habnabit> i'm already using coveralls

[16:16:21] <_habnabit> oh, you're doing built_ext -i

[16:16:34] <ionelmc> _habnabit: i'm running a sequence like tox -e 2.7,extension-coveralls,coveralls to get the coverage published

[16:16:44] <ionelmc> ah yeah

[16:16:48] <ionelmc> forgot about that

[16:17:19] <_habnabit> i guess that would do it

[16:17:23] <ionelmc> _habnabit: just so you know, this stuff in in that cookiecutter-pylibrary template

[16:35:00] <DanielHolth> ztane if the author is also the maintainer then specify the author only.

[16:42:37] <ztane> DanielHolth: author is *not* the maintainer

[16:43:16] <ztane> if I specify both author and maintainer, the PKG-INFO will *only* contain the "maintainer" as the "author"

[16:50:41] <DanielHolth> http://bugs.python.org/issue16403

[16:53:52] <Wooble> ... that really seems more of a behavior bug than a doc bug to me.

[16:56:12] <DanielHolth> If you want better, you will have to specify and implement Metadata 2.0

[16:57:30] <dstufft> I don't think that's true

[16:57:39] <DanielHolth> I suppose 1.2 exists

[16:58:42] <DanielHolth> OK, you may just have to override the pkg-info writer

[16:59:46] <DanielHolth> Prototype of wheel installer including more paths in data and "write install scheme to installed package": https://bitbucket.org/dholth/wheel/commits/all

[17:00:07] <DanielHolth> Way to generate wheels containing those extra categories pending

[17:04:18] <ztane> it is like double-wtf, if I go to pypi to do the manual registration, there is both maintainer and author fields there

[17:04:59] <DanielHolth> welcome to packaging :P

[17:05:24] <ztane> in this case (python-Levenshtein), I am the maintainer but I do not think it is appropriate to list me as the author since the author wrote about 100 % of the functionality :D

[17:06:36] <ztane> I think I will comment here: http://bugs.python.org/issue16108

[17:09:02] <dstufft> PyPI supports it just fine

[17:09:07] <dstufft> distutils doesn't send it

[17:13:01] <ztane> added a comment ^

[17:22:42] <Wooble> what's this "distutils2/metadata.py" the attachment to that issue is trying to patch? Was that ever actually in the stdlib?

[17:23:01] <DanielHolth> no

[17:35:23] <Wooble> I probably could have written a patch to implement PEP 345 in the time I just spent unsuccessfully trying to figure out why it hasn't been implemented yet.

[18:37:19] <nanonyme> What's this distutils2?

[20:23:47] <ronny> re

[20:23:56] <ronny> nanonyme: something that failed

[20:56:53] <nanonyme> ronny, if the idea was to get it into standard library, no wonder