Log file Viewer

[00:15:10] <wsanchez> ionelmc: thanks this is what I was looking for, I think

[03:12:43] <_habnabit> wsanchez, have you been pestered about cffi yet today

[06:35:13] <mgedmin> pbr ;( https://gist.github.com/anonymous/4f3631e0ed119a0876d9

[06:38:27] <mgedmin> ionelmc, are you collecting dirty build workarounds? https://github.com/mgedmin/zodbbrowser/blob/28fb1b637cb38edaf423c06bc37f9721416b0435/setup.py#L17-L37

[06:40:58] <mgedmin> ionelmc, I don't know for sure about multiple files with version numbers, but I think it's not supported: https://pypi.python.org/pypi/zest.releaser

[07:07:39] <mgedmin> anyone here familiar with pbr?

[07:07:44] <mgedmin> where does one go to file bugs against it?

[07:50:18] <trash> mgedmin: https://bugs.launchpad.net/pbr

[07:53:52] <mgedmin> thank you!

[07:55:33] <mgedmin> https://bugs.launchpad.net/pbr/+bug/1318548 yay, they'll add a link to the bug tracker to their pypi page \o/

[10:38:04] <ionelmc> mgedmin: whoa :))

[10:38:22] <ionelmc> why is that lazy string wrapper needed?

[11:27:13] <mgedmin> ionelmc, there's a comment explaining it

[11:27:35] <mgedmin> it was probably a problem in distutils of python 2.5 or 2.4, probably long-since-fixed, but I never get around to removing the workaround

[11:28:11] <ionelmc> mgedmin: aah

[11:28:19] <ionelmc> the commit history is very entertaining

[11:30:40] <ionelmc> mgedmin: yeah, about zest.releaser, i've asked the maintainer about that

[11:30:54] <ionelmc> somehow he managed to get me very angry

[11:31:39] <mgedmin> lol I'd forgotten those commits :)

[14:23:49] <pf_moore> !logs

[14:23:49] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[16:23:24] <Kronuz> hello

[16:23:46] <Kronuz> Hey, I tried uploading wheels for my new package (CodeIntel), but I got this: Upload failed (400): Binary wheel for an unsupported platform

[16:23:55] <Kronuz> (I was building in linux (Ubuntu atm)

[16:24:47] <tdsmith> pypi doesn't support uploading binary wheels for linux because ensuring binary compatibility between distros is a mess

[16:24:58] <Kronuz> :O

[16:25:06] <Kronuz> so there are no wheels for linux then?

[16:25:16] <tdsmith> not on pypi

[16:25:22] <dstufft> there are no Binary wheels for Linux on PyPI no

[16:25:27] <Kronuz> I understand

[16:25:41] <dstufft> currently the only things we can differentiate on linux is 64bit linux vs 32bit linux

[16:25:48] <Kronuz> what a mess :/

[16:26:10] <dstufft> but if you link against, say libxml2 (as lxml does), libxml2 might have completely different binary compat on different linux systems

[16:26:40] <Kronuz> one should statically link those

[16:27:15] <dstufft> there are different possible solutions

[16:27:22] <dstufft> it's not intended to be a block forever

[16:27:31] <Kronuz> ...my package contains an extension that requires libstdc++ I'm statically linking that one... and also requires libpcre (which to statically link requires the libpcre.a to be compiled using -fPIC (which isn't by default, so I have to re-compile that one too, with that flag)

[16:27:39] <dstufft> but it was a temporary-ish measure until we figure out what solution we want to use/recommend

[16:27:48] <dstufft> to prevent people from uploading a bunch of broken Wheels

[16:27:53] <Kronuz> yes

[16:27:56] <Kronuz> definitely

[16:28:15] <Kronuz> how do I tell setuptools my package needs libpcre?

[16:28:32] <Kronuz> (instead of the build failing with a "missing pcre.h")

[16:28:51] <Kronuz> (it also requires libstdc++)

[16:29:39] <dstufft> you can't really

[16:30:08] <Kronuz> it'd be nice to have it print a clean error about libpcre3-dev needed

[16:30:38] <dstufft> you can attempt to detect it inside a custom build command and print an error message

[16:30:44] <dstufft> or detect the compile failure and suggest it

[16:31:02] <Kronuz> also, on linux, compiling a package with a c++ extension results in a bunch of warnings: "cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for Ada/C/ObjC but not for C++ [enabled by default]"

[16:31:10] <Kronuz> is there a way to silent the build of an extension?

[16:31:27] <Kronuz> (so it doesn't show the whole thing with that bunch of warnings)

[16:32:25] <dstufft> Kronuz: try with the develop branch of pip, it might be silent there already

[16:32:53] <Kronuz> I meant for the package users :P

[16:33:17] <Kronuz> I thought there might be an option to silent the extensions build process (in setup.py)

[16:33:41] <dstufft> don't think so

[16:33:57] <dstufft> the next version of pip hides a lot more of that output tho

[16:34:07] <dstufft> so it should happen automatically for people when we release that

[16:34:08] <dstufft> IIRC

[16:35:29] <Kronuz> nice, because so many package users are too perky some times and panic easily

[16:35:52] <Kronuz> Donald, thank you so much for the help! I follow you on twitter and it's nice to meet you :)

[16:40:28] <dstufft> :) No problem!

[16:42:37] <Kronuz> so wheels are just for OS X and Windows, right?

[16:44:06] <dstufft> binary wheels are, you can have pure python wheels that work for all platforms of course

[16:44:53] <Kronuz> just making sure, thank you! :)

[18:39:31] <wsanchez> _habnabit: I pester myself about cffi all the time.

[19:12:06] <x0077BE> Is there any chance there's a place that has some archived or slightly out-of-date mirrors of PyPi?

[19:13:33] <x0077BE> I tried replacing the source distributions of my package because of an error in the build I hadn't caught and I removed the old files, not realizing that I wouldn't be able to upload them again with the same version number.

[19:13:55] <x0077BE> I don't want to break existing "==" dependencies, but I don't actually have the old source distributions.

[19:27:35] <x0077BE> A mirror that's at least 1 day out of date and no more than 20 days out of date would be ideal.