Log file Viewer
#pypa logs for Monday the 22nd of February, 2016
[02:48:44] <[Tritium]> benjaoming: zip sdists? eh, only if they are manually installing packages, and not using pip
[02:54:32] <benjaoming> [Tritium]: thanks! that was exactly what I wanted to know, gonna stop uploading .zips :)
[10:41:28] <dikiaap> Hi, I use command pip3 freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip3 install -U
[10:43:08] <dikiaap> but some package has error with old version. Its python-apt 0.7.8 in pip and 0.9.5 in repository elementaryOS. and default is using 0.9.5
[10:44:48] <dikiaap> how can I ignoring python-apt 0.7.8. Its recommended if I using command above and command pip install -U python-apt
[10:52:41] <Ivo> dikiaap: you should ask the python-apt project to make a newer version release on pypi
[10:54:49] <Ivo> are you trying to upgrade system python packages using pip? That might not be the best idea
[10:56:18] <Ivo> If you are wanting to do your own python developement with more up to date packages, I recommend working in a python virtualenv https://packaging.python.org/en/latest/installing/#creating-virtual-environments
[11:12:42] <Ivo> I don't know how no-cache-dir is supposed to work under a [bdist_wheel] section, or even taht it should
[11:13:45] <Ivo> nikolaosk: use requirement specifiers instead of runtime logic in your setup.py https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers
[11:22:35] <dstufft> nikolaosk: you can use environment markers to do that, but if you really want, you should make setup.py bdist_wheel error in your package
[11:23:10] <mattt> hi all, i use openstack-ansible, which basically builds all python components as python wheels
[11:23:24] <mattt> since the environment started pulling in wheel 0.29.0, i've had some wheels build that are not installable on my system
[11:23:51] <mattt> for example, on wheel 0.29.0, it's building cffi-1.5.2-cp27-cp27mu-linux_x86_64.whl, but then i cannot install that
[11:23:53] <dstufft> nikolaosk: pip has supported environment markers in wheels for as long as we have had wheels
[11:24:07] <Ivo> nikolaosk: if scrapy 1.x only supports python 2.7, then you should add [bdist_wheel]\npython-tag=py27 to your setup.cfg
[11:25:54] <dstufft> mattt: yea, the wheel version controls what tags the wheel file will contain, the pip version controls what tags pip itself will accept
[11:27:10] <dstufft> nikolaosk: override the command class with one that just always raises an exception
[11:31:15] <xafer> nikolaosk: cf https://github.com/pypa/pip/raw/develop/tests/data/packages/wheelbrokenafter-0.1.tar.gz for a dirty but simple example
[11:40:24] <Ivo> nikolaosk: your scrapyd classifiers currently say it's compatible with python 2.6, is that incorrect?
[12:03:34] <Ivo> nikolaosk: hopefully the two pull requests I made help demonstrate, at least for scrapyd's current/future versions
[12:53:57] <xafer> freeze ignores some packages (like pip, setuptools and some stdlib packages) while pip list prints everything
[13:16:53] <zakora> I didn't receive a confirmation email when registering on PyPI, is there a way to resend it?
[16:25:34] <mhils> dstufft: may I ask what's the state of https://www.python.org/dev/peps/pep-0458/ ?
[16:29:06] <Ivo> mhils: My guess is that it would only be worked on by existing people, *after* warehouse has replaced PyPI
[16:30:43] <dstufft> mhils: stalled until more pressing things and lower hanging fruit are taken care. Largely because the set of people who work on pip and PyPI *AND* who participate in the PEP process AND who know enough about cryptography to meanigfully review it and implement it... is mostly just me.
[16:32:04] <Ivo> you are ofc welcome to work on a fork of warehouse & pip (& setuptools?) that implements it / gives feedback
[16:34:17] <Ivo> man saying that over and over again for X hard feature that would be nice to have in an OSS really starts to feel shallow after a while lol
[16:35:08] <Ivo> mhils: or even just read over it carefully and write up some feedback, maybe ppl on the distutils ML would love to discuss it
[16:36:50] <mhils> I was just wondering if there is actually a prototype created by the TUF guys or not.
[16:37:28] <dstufft> I Think they have a prototype somewhere... but I'm not sure that it's in a usable state
[16:52:08] <mhils> I think I need to dig and see if they just hide the complexity there or if they deploy a lite version of the whole thing.
[17:51:15] <amsharma> Hey guys, does anyone have any idea if pypa (or pip) will be applying for GSoC this year
[22:54:53] <benjaoming> FYI this project has been alive for a bit of time in order to inform everyone of the baseline statistical correction needed for people to know *actual* downloads counts their projects are receiving: https://pypi.python.org/pypi/python-bogus-project-honeypot
[22:57:20] <ngoldbaum> hehe, no, it's just not clear to me how much CI infrastructure contributes to that
[22:57:35] <benjaoming> These are the figures that you can assume to subtract from your project's figures always:
[22:58:31] <benjaoming> ngoldbaum: true, if your project is a dependency of a lot of other projects, then their CIs account for a lot!!
[23:02:29] <njs> I wonder what I should think if I have a real project that receives substantially fewer downloads than that :-)
[23:03:14] <njs> I guess the part where it release weekly probably attracts a lot more fake downloads than are attracted to projects which release less often
[23:03:50] <njs> though using 'vanity python-bogus-project-honeypot' suggests some very weird download profiles (0 downloads for all the february releases!)
[23:15:13] <benjaoming> njs: definitely, these are the figures you should subtract from your project immediately after releasing. Daily downloads 1 month after releasing should not have the "209 downloads in the last day" subtracted. But everything should add the CI stuff that ngoldbaum mentioned, which is really hard to estimate as it's individual to any project :(
[23:17:31] <njs> monthly downloads in a month with 4 release will look very different than in a month with 1 release, too. the per-release downloads that vanity shows may be more useful, except that the numbers are hard to believe in this case :-)
[23:19:20] <njs> (maybe the best simple rule is: find the honeypot release that is closest in age to your last release, and subtract that many out of the downloads for your last release)