Log file Viewer

[10:49:09] <fladd> hi there, can anyone tell me in which intervals the PyPi download counter (JSON or via xmlrpclib) is updated? I just realized that it does not work in real-time. I downloaded a package twice, but the count did not change.

[11:23:58] <dstufft> fladd: the daily/monthly/weekly counts update in realtime-ish (minus the time it takes for it to go through the processing pipeline)

[11:24:10] <dstufft> but we aggressively cache things

[11:24:21] <dstufft> so the page or json or such can be cached

[11:24:40] <dstufft> the total downloads over time get rolled up once an hour or so

[11:30:46] <fladd> dstufft, and what about the total download count? the one that you can only get via the APIs?

[11:31:10] <fladd> ah, once an hour, sorry, should have read on :-)

[11:31:12] <dstufft> fladd: that's the one that's rolled up once an hour or so

[11:31:20] <dstufft> still subject to the caching

[11:31:30] <fladd> dstufft, cool, thanks a lot!

[13:13:19] <fladd> dstufft, It has been 3 hours now and it is still not updated. Which makes me wonder: What does count as a download? If I link directly to the file on another side, and someone downloads this one, will that count? Or does it need to be via the PyPi website or via PIP?

[13:13:35] <dstufft> fladd: it should count

[13:13:41] <fladd> mmh, strange

[13:14:38] <fladd> dstufft, well, I will give it a bit more time and see then :-) I was just hoping to use those download counts to get some idea of how much my package is used.

[13:33:16] <agronholm> dstufft: looks like we just barely missed each other last time

[13:33:31] <dstufft> agronholm: oh right, pip release

[13:33:37] <agronholm> yup

[16:29:04] <EWDurbin> any idea why building a wheel cache with `pip wheel` would fuck up version numbers of the wheels it produces?

[16:29:15] <dstufft> define fuck up

[16:29:40] <EWDurbin> tried to create a wheel cache for a project that requires “Flask_Compress== 1.2.0.1"

[16:29:48] <EWDurbin> the resulting wheel was

[16:29:54] <EWDurbin> Flask_Compress-1.2.0-py2-none-any.whl

[16:30:11] <EWDurbin> so a --no-index --find-links /opt/wheelhouse

[16:30:14] <EWDurbin> couldn’t find it on pip install

[16:30:53] <EWDurbin> failed with "No matching distribution found for Flask-Compress==1.2.0.1"

[16:32:38] <dstufft> can you do -vvv on the pip wheel

[16:32:40] <dstufft> and pastebin

[16:32:54] <ionelmc> EWDurbin: borken release

[16:33:04] <ionelmc> ask the maintainer to fix their sdist

[16:33:15] <EWDurbin> ah, that actually makes sense

[16:34:24] <EWDurbin> dstufft: ionelmc is right, pulled the sdist down and the version in the setup.py doesn’t match the version on the index

[16:34:25] <ionelmc> renaming a file to something else doesn't change the contents inside :)

[17:57:48] <mrbichel> Hi, I am having trouble installing a bunch of different packages with pip on mac os x 10.10 with python running under brew. All seems to have this errors in common '' error: Unknown value ‘10.10’ of -mmacosx-version-min" and have something to do with gcc compilation. Tried reinstalling brew and python and my virtual environments but still have the same issue. https://bpaste.net/show/1c08a9e85845

[18:00:57] <tdsmith> don't use gcc-4.2 if you can avoid it

[18:02:15] <mrbichel> how do I direct pip to use something else?

[18:03:00] <tdsmith> i think distutils will respond to the CC environment variable but maybe i'm wrong

[18:03:04] <tdsmith> how is it defaulting to gcc-4.2?

[18:03:55] <tdsmith> if the xcode compiler stubs in /usr/bin were overwritten you're generally going to be buying into weirdness

[18:04:22] <mrbichel> which gcc

[18:04:51] <mrbichel> is /usr/bin/gcc

[18:05:11] <mrbichel> under brew i have gcc-5.2.0 - but I guess that is not linked properly

[18:05:31] <tdsmith> it's probably linked but we don't install "gcc"; we install "gcc-5"

[18:05:44] <tdsmith> what's /usr/bin/gcc -v

[18:06:39] <mrbichel> https://bpaste.net/show/57fd72828811

[18:07:08] <tdsmith> looks right

[18:11:11] <mrbichel> you think I could try and manually specify another gcc version for pip?

[18:14:08] <tdsmith> yeah i would try: export CC=/usr/bin/clang; pip install my_package

[18:14:54] <mrbichel> yay that did the trick, thanks

[18:15:14] <tdsmith> python will try to use the compiler it was built with; you can see what it remembered with python -c "import sysconfig as sc; print sc.get_config_var('CC')"

[18:16:22] <mrbichel> that returns clang

[18:18:24] <tdsmith> do you think CC was already set in your environment? in a new terminal window do you get output from: echo $CC

[18:21:53] <mrbichel> yep that returns: /usr/bin/gcc-4.2

[18:22:44] <tdsmith> that'll do it

[18:24:37] <tdsmith> that's probably coming from one of your shell profile scripts; you can figure out where it's coming from with `grep CC ~/.*profile ~/.*rc` and it oughta be safe to just delete that line unless you know you need it

[18:25:04] <mrbichel> yep just found it in .profile

[18:58:28] <polyzen> what's the point of letting you specify a --build-base with `setup.py build`, but no way to use that with `setup.py install` :|

[18:58:55] <polyzen> i suppose there are plenty of reasons, but..

[19:19:25] <carljm> polyzen: It sounds like you might be trying to do something that's better done by just building a wheel.

[19:21:46] <polyzen> carljm, for split-package build scripts someone copies the sources, and builds for python3 in one and python2 in the other. it would be nice to avoid duplicating the source files by just having the python2 build/packaging use its own build dir

[19:22:15] <polyzen> am i making sense?

[19:30:53] <carljm> polyzen: Yes. That is something that's better done by building a py2 wheel and a py3 wheel. You can do that from the same sources with no problem.

[19:31:37] <polyzen> oh

[19:31:49] <polyzen> carljm, i thought you were making a "rebuild the wheel" joke :p

[19:31:58] <carljm> polyzen: Nope :-)

[19:38:00] <polyzen> carljm, so i would have to add wheel as a dep, then?

[19:39:23] <carljm> polyzen: Well, it would be needed for your build process. It doesn't need to be a dependency of your project.

[19:39:37] <carljm> It's not needed for install, either; pip can install wheels natively.

[19:40:14] <ronny> polyzen: for the build process you cn think of wheel as a setuptools plugin that makes a new format

[19:40:27] <carljm> (Though I guess your question implies that you're using `setup.py install` instead of pip. But that's an easy answer: stop doing that :-) )

[19:40:36] <polyzen> hehe

[19:40:57] <polyzen> okay, thank you

[20:44:41] <dstufft> I like how tdsmith sends a PR and apologizes for it, like he's doing something wrong ;P

[20:45:32] <tdsmith> i'm just grateful you appreciate pedantry

[20:53:41] <dstufft> if there is extra 's there at least a 85% chance it's my fault

[20:53:52] <dstufft> my brain is terrible and just randomly adds them

[23:31:37] <agronholm> dstufft: I saw the new pip release. thanks!

[23:33:08] <dstufft> agronholm: np, sorry it took me so long

[23:33:16] <agronholm> no worries, it's done now :)

[23:36:36] <agronholm> dstufft: I was able to close this now thanks to the new release: http://bugs.jython.org/issue2376

[23:36:52] <dstufft> do we work on jython now?

[23:36:57] <agronholm> indeed

[23:37:03] <dstufft> should probably figure out how to add jython to our testing matrix

[23:37:08] <dstufft> so we don't break it

[23:37:12] <agronholm> yup

[23:37:14] <dstufft> cna you open an issue so I don't forget?

[23:37:21] <dstufft> (or a PR too!)

[23:37:29] <agronholm> I'll do something :)