pmxbot IRC Log Viewer

[15:55:02] <lordcirth> Trying to pip install electrum, getting a version conflict: pytz 2012d (/usr/lib/python2.7/site-packages), Requirement.parse('pytz>=2010')

[15:55:28] <lordcirth> 2012d is obviously newer than 2010, is the "d" breaking the comparison?

[15:56:56] <dstufft> lordcirth: yes

[15:58:46] <lordcirth> dstufft, what's the cleanest way to fix?

[15:58:57] <dstufft> lordcirth: upgrade your pytz

[15:59:44] <lordcirth> dstufft, but I have the latest version in repos, 2012d?

[16:01:03] <dstufft> lordcirth: you have an updated setuptools (> 8.0), you need to either downgrade your setuptools or upgrade your pytz. If, by repos, you mean Linux repos then either you upgraded setuptools outside of those repos, or they shipped a broken configuration and you should probably raise a bug report w/ them

[16:03:06] <lordcirth> pip list | grep setup : setuptools (17.1.1)

[16:06:03] <lordcirth> dstufft, pip install pytz --upgrade fixed it, thanks

[16:31:12] <buck1> is this the right channel to ask about setuptools? i'm trying to override the way it generates SOURCES.txt but I can't find any reasonable way

[16:40:40] <ionelmc> buck1: why that file?

[16:41:08] <buck1> ionelmc: i'm trying to do a weird thing =X I want sdist to download a tarball and add it to the sdist

[16:41:21] <buck1> it seems like SOURCES.txt is what controls what goes into the sdist?

[16:43:47] <buck1> or perhaps i should just plop files into base_dir during sdist.make_release_tree, but I wasn't sure what would happen if those aren't listed in SOURCES.txt

[16:44:36] <ionelmc> buck1: no, the MANIFEST.in is

[16:44:38] <ionelmc> usually

[16:44:39] <ionelmc> :)

[16:44:50] <buck1> ionelmc: that thing is static though. I need some programmability

[16:45:07] <buck1> also when would i go grab the tarball? As an override to sdist.run?

[16:45:13] <ionelmc> buck1: nope, it's not static, it's a template (thus the .in extension)

[16:45:20] <buck1> huh.

[16:47:54] <ionelmc> buck1: https://docs.python.org/2/distutils/sourcedist.html#manifest-template

[16:48:06] <buck1> ionelmc: thanks, per usual :)

[16:48:29] <ionelmc> maybe that's not good enough

[16:48:30] <ionelmc> hmmm

[16:48:48] <ionelmc> what's this tarball downloading thing you said?

[16:50:38] <buck1> ionelmc: my repo wont contain the sources. they're in another project. sdist must go download a tarball

[16:50:55] <buck1> easily done, but I don't know where to put the code

[16:51:02] <buck1> sdist.run is the obvious choice tho

[16:51:05] <ionelmc> what about bdist?

[16:51:21] <ionelmc> or develop

[16:51:33] <buck1> bdist doesn't use sdist?

[16:51:51] <ionelmc> why would it?

[16:52:07] <buck1> to get the sources prepared i suppose

[16:52:09] <buck1> =/

[16:52:55] <ionelmc> it already has the sources no? :)

[16:53:14] <ionelmc> you should test all the setup.py commands you want to work

[16:53:15] <buck1> not in my (admittedly strange) case

[16:55:07] <ionelmc> it's unusual :)

[18:24:11] <buck1> TIL: python2.6 distutils makes the tarball twice for no reason

[18:50:02] <_habnabit> how do you predicate a dependency on python version in install_requires? specifically 'install enum34 only on old pythons'. i was doing it as an `if` in my setup.py, but that breaks because it means i have to build separate wheels for <3.4 and >=3.4

[18:50:18] <_habnabit> i thought there was a thing for this, but i can't remember it

[18:50:22] <_habnabit> and i also can't find it

[18:52:11] <tos9> 'enum34; python_version <3.4' or so

[18:52:20] <tos9> it's environment markers, they're pretty much undocumented

[18:52:21] <tos9> so find an example

[18:52:24] <tos9> I htink jsonschema has one

[18:53:09] <tos9> _habnabit: https://github.com/Julian/jsonschema/blob/master/setup.py#L27

[18:53:16] <tos9> bit different than what I said

[18:53:18] <ionelmc> _habnabit: eg: extras_require={':python_version < "3.4"': ['statistics'] },

[18:53:27] <tos9> yeah, ^

[18:53:30] <ionelmc> eh

[18:53:33] <ionelmc> you're fast

[19:26:18] <_habnabit> thanks

[20:42:27] <_habnabit> tos9, ionelmc, https://travis-ci.org/flowroute/ebb-lint/builds/84996167 erm it's failing? i copy-pasted almost exactly what was said on channel

[20:42:59] <_habnabit> or is this a tox/setuptools issue

[20:47:08] <_habnabit> going to try updating setuptools in travis..

[20:50:33] <_habnabit> exciting. looks like updating setuptools fixed the issue

[21:13:59] <buck1> ionelmc: is there any way for me to tell setuptools that my pacakge is not python-version specific but *is* architecture specific

[21:14:54] <buck1> pure-C wheels =X

[21:15:51] <ionelmc> you can prolly trick the tools to have some different wheel tag but then pip don't know about them (i think)

[21:18:49] <xafer> cf https://bitbucket.org/pypa/wheel/issues/100/binary-wheels-for-different-python ?

[22:48:42] <EWDurbin> :/ seems something in requirement parsing is getting weird with new pip/setuptools/wheel :/

[22:49:10] <EWDurbin> specifically getting `ValueError: ('Expected only one requirement', ['raven>=5.6.0', 'sentry>=7.4.0'])`

[22:49:36] <EWDurbin> not sure where to begin... i believe it's that theres a dependency that also specifies a version

[22:49:57] <EWDurbin> https://github.com/ewdurbin/sentry-datadog-helpers/blob/master/setup.py is required by the project that now fails to install

[22:50:33] <agronholm> EWDurbin: so, install_requires is empty?

[22:50:41] <EWDurbin> https://gist.github.com/ewdurbin/e2f9f6b31dc64fe77954

[22:50:47] <EWDurbin> is the requirements of the application

[22:51:04] <EWDurbin> yes, install_requires is empty unless one of the extras is specified

[22:51:40] <EWDurbin> so just remove https://github.com/ewdurbin/sentry-datadog-helpers/blob/master/setup.py#L41

[22:51:43] <EWDurbin> ?

[22:52:08] <agronholm> seems unnecessary yes, but removing ofc won't fix your problem

[22:52:21] <agronholm> I don't see anything wrong with this setup.py

[22:52:55] <EWDurbin> this fails specifically while trying to build a wheel cache

[22:53:03] <EWDurbin> $ pip wheel --wheel-dir=osfiles/opt/wheelhouse .

[22:53:10] <agronholm> I take it you have the latest versions of everything?

[22:53:13] <EWDurbin> yes

[22:53:20] <EWDurbin> hrm

[22:53:23] <EWDurbin> well maybe not pip

[22:53:27] <EWDurbin> i can enforce latest pip

[22:53:35] <agronholm> see if that helps

[22:55:22] <EWDurbin> agronholm: horray! new an different error!

[22:55:26] <agronholm> ?

[22:55:30] <EWDurbin> `ValueError: too many values to unpack`

[22:55:36] <agronholm> traceback?

[22:55:42] <EWDurbin> gisting

[22:56:11] <EWDurbin> https://gist.github.com/ewdurbin/30fed8302235860a2cf3

[22:56:24] <EWDurbin> oh hey

[22:56:29] <EWDurbin> oh. no

[22:56:31] <EWDurbin> :/

[22:56:33] <agronholm> ?

[22:56:54] <EWDurbin> i thought this build was public

[22:56:56] <EWDurbin> it is not

[22:57:08] <agronholm> ...?

[22:57:28] <EWDurbin> i was just going to link to the travis build...

[22:57:31] <EWDurbin> then realized i could not

[22:58:08] <EWDurbin> seems it is failing to build the wheel for the public thing though

[23:01:26] <agronholm> EWDurbin: I was able to build a wheel and sdist for it just fine

[23:01:40] <agronholm> and install said wheel

[23:01:44] <EWDurbin> yes, wheel/sdist for sentry-datadog-helpers is fine

[23:01:51] <EWDurbin> but the dependent project seems to explode

[23:02:14] <agronholm> so it seems that looking at this setup.py is pointless

[23:02:33] <agronholm> that gist with the requirements = [...]

[23:02:41] <agronholm> is from the other project's setup.py?

[23:02:44] <EWDurbin> yes

[23:02:56] <agronholm> care to gist the entire file?

[23:02:57] <EWDurbin> agronholm: i'm attempting to create a minimal failing case right now

[23:03:26] <EWDurbin> agronholm: https://gist.github.com/ewdurbin/63bb648c0241aeb41ee9

[23:03:47] <agronholm> python syntax highlighting would help, but I'll go with this

[23:04:11] <EWDurbin> agronholm: refresh

[23:04:19] <agronholm> thx

[23:05:02] <agronholm> btw did you know scripts= is not the best way to do console scripts?

[23:05:03] <EWDurbin> FWIW: this build was working fine. this was actually just rebuilding the latest release

[23:05:18] <EWDurbin> agronholm: yeah... habitual. entry_points... right?

[23:05:23] <agronholm> yup.

[23:06:01] <EWDurbin> 99% of setup.pys are cargo-culting IIRC

[23:06:02] <EWDurbin> ;)

[23:06:15] <EWDurbin> :(

[23:06:40] <agronholm> you might also want to consider setuptools_scm

[23:06:57] <EWDurbin> for versioning?

[23:06:57] <agronholm> if that suits your development process ofc

[23:07:01] <agronholm> yes

[23:07:22] <EWDurbin> i'll take a look... right now i'm just real sad that this build started breaking random like

[23:07:58] <EWDurbin> agronholm: that does look super sweet though

[23:07:59] <EWDurbin> thanks

[23:08:39] <agronholm> I've switched most of my own projects already

[23:08:44] <EWDurbin> is this due to raven being specified twice?

[23:08:58] <agronholm> hmm

[23:09:02] <EWDurbin> so raven>=5.6.0 is required by sentry-datadog-helpers

[23:09:11] <agronholm> do they require conflicting raven versions?

[23:09:13] <EWDurbin> and raven[flask]==5.6.0 is required by the client

[23:09:25] <EWDurbin> aka the application

[23:09:30] <EWDurbin> that's using sentry-datadog-helpers

[23:09:36] <agronholm> hard to say until you produce that test case

[23:09:43] <EWDurbin> workin.

[23:10:32] <EWDurbin> at this point it appears to be a bug in wheel

[23:15:53] <ionelmc> EWDurbin: " raven[flask]==5.6.0" causes the issue?

[23:17:16] <EWDurbin> seems even with >= it fails

[23:17:47] <EWDurbin> removing raven[flask] deep completely doesn't help either

[23:18:39] <EWDurbin> but, removing sentry-datadog-helpers is great

[23:18:49] <EWDurbin> :|

[23:19:47] <dstufft> EWDurbin: it works if you remove sentry-datadog-helpers?

[23:19:59] <EWDurbin> yeah, so it seems to be something with 1.0.3

[23:20:02] <EWDurbin> latest release of that is fine

[23:20:05] <EWDurbin> let's see the diff

[23:21:18] <EWDurbin> so this is my bad. but https://github.com/ewdurbin/sentry-datadog-helpers/compare/1.0.3...1.1.1#diff-2eeaed663bd0d25b7e608891384b7298L14

[23:21:27] <EWDurbin> something in that diff of the setup.py fixed the issue

[23:22:00] <EWDurbin> :/

[23:22:22] <dstufft> removing the test_requires did it

[23:23:30] <dstufft> tests_require = ['mock==1.3.0',] + [raven_requires + sentry_requires] is the same as tests_require = ['mock==1.3.0',] + [raven_requires = ['raven>=5.6.0',] + ['sentry>=7.4.0', 'datadog==0.9.0',]]

[23:23:39] <dstufft> notice the double lists

[23:23:40] <EWDurbin> ah

[23:23:43] <EWDurbin> whoooops

[23:23:57] <EWDurbin> gah, didn't realize i had released a new version anyway

[23:23:58] <dstufft> your data structure is still wrong, but it's not failing in master because you stopped passing in test requires

[23:24:11] <EWDurbin> thanks, will fix that up

[23:25:27] <dstufft> EWDurbin: let me know if it doesn't work

[23:28:50] <EWDurbin> all better. thanks dstufft and agronholm

[23:29:35] <agronholm> why didn't I see this -_-

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 12th of October, 2015