pmxbot IRC Log Viewer

[06:32:56] <MarkusH> What's the recommended way to get the installed version of a package during runtime? http://stackoverflow.com/a/2073599 looks promising

[06:35:29] <ronny> MarkusH: the way to do it by metadata is pkg_resources.get_distribution('myproject').name

[06:35:34] <ronny> whpos wh version

[06:35:48] <MarkusH> ronny: cheers!

[07:16:37] <MarkusH> ronny: works like a charm :)

[07:21:43] <tx> Hey guys, I may have a bit of a weird request. We cache pip packages locally for fast CI / software builds. Only problem is that sometimes these packages take some time to build.

[07:22:05] <tx> Is there some sort of pre-built remote wheel / egg repo?

[07:22:27] <tx> Aim is to pre-build for a specific python version + arch. Save a lot of time.

[10:54:14] <ronny> tx: you could put a devpi in the middle build a wheel and upload it with twine

[10:54:24] <ronny> tx: that way you controll the building anf the timing

[10:54:35] <ronny> and devpi can be configured not to get new versions from pypi

[13:58:28] <daniel_holth> Hi

[14:26:40] <dstufft> pombreda: No, the fact it's old is how it generally works :)

[14:38:47] <pombreda> dstufft: I reckon this :P welll guess what .... not sure how, but lxml has just pubslihed manylinux wheels there https://pypi.python.org/pypi/lxml/3.6.4 .... so these may be working. let me test

[14:40:30] <pombreda> dstufft: I wonder why Centos has been picked rather than debian.... nefore many Linux I have had faily good sucess with older debians for eggs, then wheels

[14:41:41] <dstufft> pombreda: other people doing this sort of thing (Enthought, Anaconda, Holy Build Box, etc) were all using CentOS5, so we just went with the crowd

[14:43:09] <pombreda> fair enough

[14:49:19] <daniel_holth> Hello pombreda

[14:49:29] <pombreda> daniel_holth: Hi there :)

[14:56:48] <pombreda> daniel_holth: I should have some time later this week to submit you some PR bits for PEP 491

[14:56:58] <daniel_holth> Neat

[14:58:09] <pombreda> mgedmin: I have been referring several ugly Pypi package pages due to faulty ReST to your restview ... :) I hop this is not bugging you

[15:09:49] <pombreda> !logs

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

[20:51:50] <pombreda> can I use https://www.python.org/dev/peps/pep-0496/ in intall_requires? with the latest setuptools/wheels and to build wheels?

[20:53:08] <DanielWHolth> It only works in extras-require in wheel. Nb its bug tracker

[20:56:09] <pombreda> DanielWHolth: thx. I am trying this simple stuff: lxml 3.6.0 builds on windows as a wheel. It fails on 3.6.4. But work on 3.6.4 for manylinux (which does not works on 3.6.0) ...

[20:56:32] <ngoldbaum> fun!

[20:56:53] <pombreda> So I would want to have lxml==3.6.0 for windows and lxml==3.6.4 otherwise (linux and mac)

[20:57:28] <pombreda> and fwiw any version between 360< <364 have otherr problems

[20:58:04] <ngoldbaum> pombreda: are you an lxml maintainer?

[20:58:22] <pombreda> Thank god, I am not :D

[20:58:27] <ngoldbaum> heh

[20:58:35] <ngoldbaum> i get the impression they don't do continuous integration

[20:58:39] <ngoldbaum> thus breakage like this

[20:58:59] <pombreda> not really and the various pre-built on pypi seem like an afterthought

[20:59:10] <ngoldbaum> doing wheels right is hard

[20:59:19] <ngoldbaum> ideally you want them built at the same time as the sdist

[20:59:25] <ngoldbaum> but that takes a lot of coordination

[20:59:33] <pombreda> yep

[20:59:34] <ngoldbaum> since you need build machines on three OS choices

[20:59:53] <pombreda> that I have: you can see the build loop there: https://github.com/pombreda/thirdparty and https://github.com/pombreda/thirdparty-manylinux

[21:00:10] <pombreda> on windows@appveyor and linux/mac@travis

[21:00:25] <pombreda> and this is all automated

[21:00:58] <pombreda> now to add some twist, lxml does not build on a bare manylinux docker after version 3.3.6

[21:01:18] <pombreda> because it requires more modern libxml2 and libxslt

[21:02:01] <pombreda> but a 3.3.6 lxml build on the manylinux docker image segfaults on Ubuntu 14 64 which is a ratherr mainline distro

[21:03:35] <pombreda> ngoldbaum: you know it all

[21:03:41] <pombreda> now :)

[21:04:04] <ngoldbaum> pombreda: sounds like fun

[21:04:10] <ngoldbaum> and sounds like you need to track down an lxml maintainer

[21:04:31] <ngoldbaum> maybe setup CI for them :)

[21:04:51] <pombreda> ngoldbaum: yeah I will try to ping scoder tomorrow.... I want my scancode toolkit to run out fo the box on linux/mac/win

[21:06:27] <pombreda> actually lxml is _tested_ on appveyor/win and travis/linux (aka Ubuntu 12 64)

[21:06:35] <pombreda> but not built on the CI

[21:06:53] <apollo13> 32 bit binaries? does that still exist? :D

[21:06:59] <ngoldbaum> on windows

[21:07:02] <ngoldbaum> and linux :/

[21:07:18] <ngoldbaum> less so on linux these days

[21:07:26] <apollo13> windows okay, but if someone does it on linux nowadays -> wtf

[21:07:28] <pombreda> apollo13: I wish it would not, but I live in the real world

[21:07:36] <apollo13> centos does not even offer 32 bit anymore

[21:07:38] <ngoldbaum> centos 5 is still a thing for some people :)

[21:07:51] <apollo13> they can build their things on their own :D

[21:08:06] <pombreda> and is the least common denominators on many distros

[21:08:38] <apollo13> 32 bit? ;)

[21:08:45] <pombreda> apollo13: nope centos 5

[21:08:56] <pombreda> anyway this is not the debate :)

[21:09:19] <apollo13> well, reducing the number of build combinations might make it easier to find a workable version ;)

[21:10:10] <ngoldbaum> someone was complaining about this on reddit recently...

[21:11:04] <ngoldbaum> or hmm maybe not, can't find it

[21:11:14] <apollo13> segfaults? but more on ubuntu 16 due to cpp api/abi changes

[21:11:23] <apollo13> 14.04 should be relatively fine

[21:12:30] <pombreda> well not with the manylinux 64 build for lxml 3.3.6

[21:12:45] <pombreda> let me try the extra_requires

[21:12:56] <apollo13> what does the trace say?

[21:19:34] <pombreda> apollo13: I will know in a sec: https://ci.appveyor.com/project/nexB/scancode-toolkit/build/682

[21:19:44] <pombreda> I do not have a windows box handy :P

[21:20:03] <pombreda> It works!

[21:20:34] <pombreda> and there too: https://travis-ci.org/nexB/scancode-toolkit

[21:21:00] <pombreda> DanielWHolth: You are the best !

[21:21:17] <DanielWHolth> 😇

[21:21:48] <pombreda> that is ratherr under documented in the PEPs imho, but is works superbly

[21:22:01] <apollo13> oh, I ment the segfault trace, but great it works for you

[21:22:53] <pombreda> apollo13: I did not waste time to investigate the lxml manylinux segfault trace as the lxml maintainers published a working manylinux offocial wheel on Pypi this week -end

[21:23:02] <apollo13> ah

[21:23:16] <pombreda> (I mean the non working one build with lxml 3.3.6 and the many linux docker images)

[21:26:32] <pombreda> DanielWHolth: and it works great so far :) thank you really very much... For anyone who would want this here is the commit for the IRC logs: https://github.com/nexB/scancode-toolkit/commit/789ef18f620c98efdf7cdc9f9853ea494cb45bc4#diff-2eeaed663bd0d25b7e608891384b7298L110

[21:27:02] <pombreda> this made my day !

[21:28:14] <pombreda> so DanielWHolth I reckon that using extra_requires with environment markers does not require a special pip invocation then?

[21:32:35] <DanielWHolth> The empty extra name is equivalent to an install req

[21:34:44] <pombreda> DanielWHolth: this explains it all.... Thank you my Lord.

[21:36:34] <pombreda> I guess I condemned to push a patch to https://github.com/pypa/python-packaging-user-guide/ explaining how to do this in simple terms :P

[21:36:44] <pombreda> *I am condemned

[21:38:14] <pombreda> or not: my last PR there was a year ago: https://github.com/pypa/python-packaging-user-guide/pull/160 and has still not be pulled in? :|

[21:39:49] <pombreda> well I will do it any way :P

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 22nd of August, 2016