pmxbot IRC Log Viewer

[01:13:55] <Guddu> Could someone please help me with this SO query?

[01:13:55] <Guddu> stackoverflow.com/questions/29615736/pymssql-on-rhel-6-5-freetds-installed-using-source-in-opt-app-freetds

[18:33:21] <warner> dstufft: hey, so reaperhulk said I should ping you with a funny setuptools-vs-pyasn1 question. Got a minute?

[18:43:07] <aclark> warner: you had me at "funny"

[18:43:30] <warner> heh

[18:43:40] <warner> so foolscap.lothar.com/trac/ticket/231 is where I'm tracking the problem

[18:44:00] <warner> basically 'setup.py install' from my package fails the first time, but succeeds if you run it again right away

[18:44:58] <warner> somewhere down the dependency chain, my package uses pyasn1, and "setup.py install" installs it, but then something else during the install process refuses to believe that it's present, and it bails

[18:46:50] <aclark> warner: you can also open a setuptools ticket if you suspect a bug, fyi: bitbucket.org/pypa/setuptools

[18:47:32] <warner> thanks

[18:47:49] <warner> I don't yet understand the problem enough

[18:52:46] <ronny> warner: does pip install . work the first time?

[18:53:32] <ionelmc> i bet on garbage in site-packages triggering bug in setuptools

[18:53:35] <ronny> (setuptools install has workingset invariants that mess the whole world up)

[18:53:42] <ionelmc> warner: does it reproduce on empty env?

[18:54:21] <ronny> ionelmc: pretty much the opposiste, i suspect there is a "setup requires" thats not declared properly, so easy_install fails correctly the first time

[18:54:58] <ionelmc> ronny: lol how much do you bet?

[18:55:15] <ionelmc> beer is good for currency

[18:55:37] <ronny> one beer od choice sounds like a god idea, unless you prefer something else ^^

[18:55:54] <warner> ionelmc: it reproduces on an empty virtualenv

[18:56:07] <warner> 'pip install foolscap.tar.gz' worked fine

[18:56:13] <ionelmc> damn

[18:56:14] <warner> I'll try 'pip install .' next

[18:56:55] <ronny> ionelmc: im relatively sure that the issue is a setup_requires not being declared and the general install workingset not autoupdating ^^

[18:57:28] <ronny> ionelmc: i learned why hell has a ice scating team when settin up python setup.py develop

[18:58:00] <ionelmc> lol

[18:58:08] <warner> hrm, now that's a funny line in the output: /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'extra_requires'

[18:58:14] <warner> how did distutils get control there?

[18:58:39] <ronny> warner: when doing what?

[18:58:56] <warner> "python setup.py install" from foolscap

[18:58:58] <_habnabit> warner, oh, your logs here are from you doing `setup.py install`, which wouldn't use pip

[18:59:03] <warner> yeah

[18:59:56] <_habnabit> warner, installing with non-pip kind of sucks, haha

[19:00:00] <warner> yeah

[19:00:12] <warner> _habnabit: got a minute/interest to look at this in person?

[19:00:14] <_habnabit> hmm

[19:00:16] <_habnabit> warner, yeah, one sec

[19:00:26] <ronny> hmm, im just reminded of the hell that trac and just sel-hosting is ^^

[19:49:39] <ronny> dstufft: ping? any oppinion on having a tool:pip section in tox.ini that can declare extra commands to obtain egg/dist info, and install/develop commands?

[19:53:53] <ronny> dstufft: and on the same page, any oppinion on having a pip sdist command?

[20:05:37] <warner> ok, _habnabit convinced me to not worry too much about 'python setup.py install' not working, and to have my docs recommend 'pip install .' instead

[20:06:58] <_habnabit> i am curious what the issue is though

[20:07:06] <_habnabit> and i bet it's those damned eggs

[20:09:15] <warner> yeah

[20:09:59] <ronny> warner: the problem is likely a undeclared setup_requires, setup.py should be able to execute without dependencies

[20:10:43] <warner> yeah, I looked at the most suspicious modules, and none of them were importing anything surprising

[20:15:17] <ronny> warner: the problem is setup.py scripts

[20:16:15] <ronny> warner: while setup.py install runs, easy install will pull in new packages that are not yet part of the current workingset, so a subsequent setup with a missing setup_requires will fail on the first run due to the requirement not being in the current workingset

[20:16:29] <ronny> however the subsequent invocation will contain them in the current workingset, thus succeed

[20:19:51] <warner> ronny: so the problem would be a module which does 'import foo' but which *doesn't* do a 'setup_requires=["foo"]', right?

[20:23:48] <aclark> ronny: nice

[20:27:12] <ronny> warner: likely

[20:27:25] <ronny> aclark: what do you mean?

[20:27:30] <warner> ronny: ok, thanks, I'll look for that

[20:27:37] <warner> haven't found it yet, but I'll keep looking

[20:28:13] <ronny> warner: good luck, its likely soemhing different

[20:28:44] <ronny> warner: like some pacakge iporting its version module, and its __init__.py importing stuff that imports dependencies

[20:31:27] <aclark> ronny: i mean good catch

[20:31:51] <ronny> its just a common problem

[20:32:21] <ronny> bad packages are common with setuptools in some way, its too easy to get it wrong but it somhow works, in particular if you rin things twice ^^

[20:40:22] <iElectric> anyone familiar with docker?

[20:40:27] <iElectric> how do I enter web container?

[20:40:31] <iElectric> docker attach web

[20:40:33] <iElectric> hangs

[20:41:31] <doismellburning> iElectric: try #docker?

[21:00:27] <iElectric> got id

[21:00:29] <iElectric> it*

[21:33:39] <mathu> if i run pip, this happens: bpaste.net/show/9c6a103f4f31

[21:33:49] <mathu> this all started when i ran pip as sudo and then frowned really hard because it broke portage (i am on gentoo)

[21:34:12] <mathu> how might i fix this? i just ran `q file -q /usr/lib/python* | sort -u` to output all packages with files installed in python directories and rebuilt everything that it output, to no avail

[21:45:18] <ronny> mathu: its unclear what you broke, but i suspect you better rebuild everything that touched /usr/lib64/python3.3/site-packages/

[21:45:24] <ronny> i havent used gentoo in ages

[21:45:49] <_habnabit> mathu, you've learned to not run pip as root now, right

[21:46:32] <ronny> i fail to see why for a gentoo user the first instinct isnt to make a ebuild

[21:50:49] <mathu> _habnabit: see, i already knew, and did it anyway haha

[21:51:01] <mathu> i'd learned this lesson on debian by breaking system perl :P

[22:25:31] <ronny> jaraco: sup

[22:53:49] <mathu> rebuilding everything in /usr/lib64/python3.3/site-packages did not fix anything :(

[22:54:10] <mathu> i think that was what i accomplished initially with /usr/lib/python* though

[22:54:56] <jaraco> hi ronny

[22:55:43] <jaraco> I'm trying to deploy dev devpi, but pip is failing me. :/

[22:56:07] <jaraco> Could not find a version that satisfies the requirement devpi-common<2.1,>=2.0.6.dev0 (from devpi-server==2.2.0dev4->-r requirements.txt (line 2)) (from versions: 1.2, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6.dev2)

[22:56:19] <ronny> jaraco: use --pre?

[22:56:33] <jaraco> aah.

[22:56:37] <ronny> jaraco: also ash holger in detail

[22:56:48] <jaraco> Excellent idea.

[22:56:49] <jaraco> !m ronny

[22:56:49] <pmxbot> you're doing good work, ronny!

[22:57:10] <ronny> jaraco: i have some upcoming things for setuptools to discuss, when would be a good time?

[22:57:54] <jaraco> good question. Tomorrow afternoon, probably.

[22:58:01] <jaraco> Or next Wednesday.

[22:58:37] <jaraco> I'll be on vacation Fri-Tues, so schedule will be unpredictable and intermittent Thu-Tues.

[23:00:00] <ronny> jaraco: is twitter based coordination fine? im off to bed now, 1 am

[23:01:53] <jaraco> ronny: that works if I'm not here.

[23:23:23] <jaraco> ugh. It seems it's not possible to specify --pre in requirements.txt. Maybe PIP_PRE env var.

[23:25:30] <dstufft> jaraco: you can just include a pre release in the specifier, so like >=0.0.dev0 will work for that

[23:26:08] <jaraco> dstufft: the specifier is >=2.0.6.dev0

[23:26:16] <jaraco> well

[23:26:22] <jaraco> <2.1,>=2.0.6.dev0

[23:26:43] <dstufft> I think it's the <2.1 part that disallows it, sec let me verify

[23:26:51] <dstufft> possibly that needs tweaked

[23:27:55] <jaraco> You can probably replicate with: pip install -i devpi.net/hpk/dev/+simple devpi-server==2.2.0dev4

[23:28:37] <dstufft> hrm

[23:29:14] <dstufft> >>> list(packaging.specifiers.SpecifierSet("<2.1,>=2.0.6.dev0").filter(["1.2", "2.0.0", "2.0.1", "2.0.2", "2.0.3", "2.0.4", "2.0.5", "2.0.6

[23:29:14] <dstufft> .dev2"]))

[23:29:14] <dstufft> ['2.0.6.dev2']

[23:29:22] <dstufft> so it certainly works inside packaging

[23:29:27] <dstufft> so something pip is doing it messing it up

[23:30:05] <jaraco> I also tried setting PIP_PRE=true, but that didn't help.

[23:30:13] <jaraco> (env var)

[23:30:33] <jaraco> Though I'm not sure the technique actually set the variable properly.

[23:30:56] <dstufft> jaraco: can you verify what version of pip

[23:31:15] <jaraco> 6.1.1

[23:32:33] <jaraco_> also 6.0.8

[23:34:27] <dstufft> hum

[23:34:28] <dstufft> strange

[23:34:32] <dstufft> something odd is going on

[23:35:00] <jaraco_> aha

[23:35:17] <dstufft> I'm getting different results each time I execute pip

[23:35:17] <jaraco_> it works if I specify devpi-server==2.2.0.dev4

[23:35:21] <jaraco_> oh

[23:36:33] <jaraco> Indeed. I'm getting inconsistent results.

[23:36:40] <jaraco> I also got the failure with 2.2.0.dev4

[23:37:28] <jaraco> But I repeat a few times and it works eventually.

[23:38:17] <jaraco> dstufft: I'm out of time to troubleshoot this. Would you like me to file a ticket?

[23:38:50] <dstufft> jaraco: yea, I think this is a fault of the packaging lib, which means that setuptools is probably affected as well

[23:39:13] <jaraco> so file it with packaging or pip?

[23:40:00] <dstufft> packaging I think

[23:40:07] <dstufft> python -c "from packaging.specifiers import SpecifierSet; print(list(SpecifierSet('<2.1,>=2.0.6.dev0').filter(['1.2', '2.0.0', '2.0.1', '2.0.2', '2.0.3', '2.0.4', '2.0.5', '2.0.6.dev2'])))"

[23:40:13] <dstufft> that reproduces the inconsistency

[23:40:18] <dstufft> if you re-run that you get different answers

[23:40:37] <dstufft> probably it's related to the oder the underlying specifiers inside the SpecifierSet are evaluated

[23:40:53] <dstufft> which SpecifierSet holds each Specifier inside a set, so the order is going to be undefined

[23:42:41] <dstufft> heh

[23:42:43] <dstufft> I see the problem

[23:42:46] <jaraco> github.com/pypa/packaging/issues/28

[23:42:49] <dstufft> the problem is I'm an idiot

[23:43:09] <jaraco> !thanks dstufft

[23:43:09] <pmxbot> you're doing good work, dstufft!

[23:43:25] <dstufft> now to figure out what the _right_ answer is here

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 14th of April, 2015