Log file Viewer

[04:01:33] <dhubbard> I got a packaging issue that's driving me nuts. My Linux CI pipeline keeps generating wheels with the platform set to any, which of course means they won't install on my Mac.

[04:21:44] <tomprince> dhubbard: Are you sure? 'any' packagse should be platform independant.

[04:30:48] <dhubbard> My package isn't platform independent and I can't figure out how to get it to quit setting the platform to any

[04:31:28] <thedodd> Greetings all. I'm wondering if anyone here has experience with setuptools entry_points. Particularly, if anyone has had success registering a **package** as an entry point. I can register modules, classes, functions &c as entry points, but I've not had any luck with packages.

[04:31:46] <thedodd> PS also asking the the #python channel, figured I'd ask here as well.

[04:32:53] <thedodd> dhubbard, you should be able to specify the platforms in your setup.cfg or on the command line.

[04:33:11] <thedodd> **should**

[04:33:40] <dhubbard> Hmm, I haven't been able to find anything about how to do that in my searching.

[04:36:06] <thedodd> dhubbard, let me take a look real quick. You are using the wheel format?

[04:36:33] <dhubbard> Yes, the sdist package works fine.

[04:36:42] <tomprince> dhubbard: Is your package pure python?

[04:37:28] <dhubbard> Nope, it embeds redis in the package. So has c compiled components

[04:45:37] <thedodd> dhubbard, sorry for the late response

[04:45:53] <thedodd> I'm pretty sure that it is the --plat-name | -p to bdist_wheel command

[04:46:04] <dhubbard> No reason to be sorry ;-)

[04:46:09] <thedodd> that should do it. Make sure that --universal is set to 0

[04:46:14] <dhubbard> Is it possible to add it to the setup.cfg

[04:46:18] <thedodd> yes

[04:46:30] <dhubbard> Yes, I already set universal to 0 at least

[04:46:31] <thedodd> put it under the [bdist_wheel] subsection of your cfg

[04:46:51] <thedodd> let me know if any of that works for you

[04:50:40] <dhubbard> Thanks, I hope so.

[22:45:40] <peke_> dstufft: I was here earlier asking about proxy support with pip. I thought it could be enhanced by using urllib.getproxies that I though requests didn't use.

[22:45:59] <dstufft> peke_: I remember yup

[22:46:39] <peke_> Turned out I was wrong. The reason pip doesn't work out-of-the-box in my client's environment is that it is configured using PAC: http://en.wikipedia.org/wiki/Proxy_auto-config

[22:47:30] <peke_> If proxy is set manually in system config pip/requests/urllib3 reads it just fine.

[22:50:32] <dstufft> peke_: ok

[22:50:38] <dstufft> peke_: is there a way to get that from within python?

[22:50:56] <peke_> There's http://code.google.com/p/pacparser/

[22:52:05] <peke_> It contains spidermonkey to evaluate pac files (they are javascript) and some C code to interact with it. Would be quite a big dependency for pip.

[22:53:20] <dstufft> ouch

[22:53:28] <dstufft> yea we're unlikely to be willing to do that :(

[22:54:02] <dstufft> if that's what is required, the best I think we can hope for is if there's a python library on PyPI that provides an API that uses that, is we can optionally use it if it is installed

[22:54:24] <peke_> Yeah, I didn't even want to propose it. It's not that hard to either set proxy manually or set https_environment variable (which urllib.getproxies checks first).

[22:56:30] <peke_> It seems to be only available through Google Code project pages. Project hasn't been too active lately.

[22:57:20] <peke_> But even if it was available on PyPI, one needed to first configure proxy to be able to install it with pip. Chicken and egg. I guess that's also the reason pip vendors requests and other packages.

[22:57:40] <dstufft> peke_: that's one of the reasons pip vendors requests yes

[22:58:09] <dstufft> also because ``pip install requests==1.0`` should not break pip because if you break pip you can't ``pip install requests==2.5.0`` to fix pip

[22:59:01] <peke_> The best solution obviously would be if urllib.getproxies would handle PAC. Don't see that happening in 2.x, though.

[23:01:41] <peke_> Anyway, now that I know the limitations I can update installation instructions for people behind proxies. If you are interested, I could take a look at improving pip's docs too. Could then just point there from our instructions.

[23:05:52] <dstufft> peke_: we're always interested in doc improvements!

[23:08:17] <peke_> Cool, I'll take a look at the current proxy docs and see could they be improved.

[23:13:40] <dstufft> I'm not even sure if we have proxy docs at all :(

[23:13:43] <dstufft> we might I'm not sure

[23:13:49] <dstufft> I've never had to use a proxy :(

[23:14:58] <peke_> dstufft: you should be =) for never using a proxy

[23:15:16] <dstufft> peke_: well I'm sad because I don't really know how well it works for people who need to use it :)

[23:15:28] <dstufft> I don't think we even really test that it works at all

[23:15:41] <dstufft> although that is much better now adays since we use requests

[23:17:07] <peke_> I briefly looked and it seems pip doesn't have real proxy docs. Under docs directory I found references to proxy only in installing.rst when using get-pip.py.

[23:19:01] <peke_> Additionally --proxy command line option is documented.

[23:19:58] <peke_> I'll take a look where a section about proxies could be added when I have more time. Most likely after Python 2.7.9 because then I can also updated our installation instructions to recommend using it on Windows to get pip automatically.

[23:20:25] <peke_> That's probably something that should be also mentioned at https://github.com/pekkaklarck/pip.git

[23:21:29] <peke_> Ooops, wrong url. This is where pip being included in Python 2.7.9 on Windows (and OSX?) should be added: https://pip.pypa.io/en/latest/installing.html

[23:22:10] <dstufft> peke_: ah yes that's true :)

[23:53:36] <superkuh> I can't recall who it was but thanks for all the help a few days ago. I managed to fix my python install once you pointed out it wasn't pip's fault. Much thanks.