Log file Viewer

[07:06:08] <the8thbit> Whenever I try to install any package with sudo pip install NAME I get an ImportError: cannot import name ContextualZipFile

[08:38:36] <Ivo_> the8thbit: try reinstalling setuptools

[10:09:47] <pombreda> Howdy fierce packagers ... I am migrating complex configs from buildout to pip. One of the thing I had in contributed to buildout was the ability to have conditional package installation based on some os/arch/platform conditions

[10:09:56] <pombreda> I could not find something in pip

[10:10:04] <pombreda> So I am using this atm: https://gist.github.com/pombredanne/72130ee6f202e89c13bb

[10:10:25] <pombreda> would there be a better, built-in way to achieve this?

[10:16:10] <pombreda> which is essentially porting the logic I commited in buidout in there https://github.com/buildout/buildout/blob/master/src/zc/buildout/buildout.py#L1442 and there https://github.com/buildout/buildout/blob/master/src/zc/buildout/configparser.py#L127

[12:01:39] <staticshock> i have a long project name that i was hoping to separate the words in. should i go with long-name or long_name in setup.py?

[12:16:22] <Ivo_> pombreda: http://wheel.readthedocs.org/en/latest/#defining-conditional-dependencies

[12:19:12] <Ivo_> staticshock: if its namespace-separation-like, I'd use periods. Otherwise, in version comparison, - and _ are actually equivalent. I think - looks better in package names, but maybe thats just me

[12:19:30] <Ivo_> http://legacy.python.org/dev/peps/pep-0426/#name

[12:23:52] <staticshock> Ivo_: i'm struggling with it

[12:24:06] <staticshock> i went with dashes, and now i can't actually install it via pip

[12:24:21] <pombreda> Ivo_: you wrote "I think - looks better in package names" ... that is a quasi de-facto standard amost everywhere ;)

[12:24:34] <staticshock> Ivo_: here's the package: https://pypi.python.org/pypi/colored-traceback

[12:24:50] <Ivo_> "quasi de-facto" doesn't sound very standard to me :P

[12:24:59] <staticshock> pip install colored-traceback fails, and pip install colored_traceback also fails

[12:26:17] <staticshock> before the install fails, pip actually states: "Real name of requirement colored_traceback is colored-traceback"

[12:26:22] <pombreda> Ivo_: I menat by that that dash are consistently used for packages of linux distro, and most commonly in python, ruby, npm, etc

[12:26:23] <staticshock> so it KNOWS it's threre, but it's failing anyway

[12:27:06] <Ivo_> staticshock: I'm getting a TooManyRedirects error, so it might be a pypi side error

[12:27:23] <staticshock> oh, okay

[12:27:37] <staticshock> so maybe they'll fix it on their end

[12:27:59] <staticshock> i uploaded it, deleted, and re-uploaded. so that might be causing some issues, i guess.

[12:31:00] <pombreda> staticshock: avoid re-uploading the same version if possible ;)

[12:31:17] <pombreda> bump it as a minor if you goofed

[12:32:14] <staticshock> pombreda: i didn't just re-upload the same version, i *deleted the package on pypi*, then re-registered, re-uploaded

[12:32:26] <staticshock> because i've been trying to figure out what the appropriate naming conventions are

[12:33:44] <pombreda> staticshock: well, agreed, but things once released should be either deleted in rare security cases or revved up imho... the redirect issue you are getting is likely because of your meddling with things?

[12:34:06] <pombreda> staticshock: colored-traceback is quite fine :P

[12:34:33] <Ivo_> staticshock: did you change the packages name at all between reuploading it?

[12:39:38] <staticshock> Ivo_: nope, i think i went back to whatever the old name was

[12:39:57] <Ivo_> *went back to*? that implies you did change something

[12:40:19] <staticshock> yep, i tried colored-traceback, then colored_traceback, then colored-traceback again

[12:40:57] <staticshock> shit just didn't work the way i expected it to. and yes, i will delete things at will to try to fix it. and no, you can't stop me. until there's a clear approach to doing things, i have to tinker to figure this out.

[12:41:16] <staticshock> pombreda: fine in terms of being able to install it?

[12:41:28] <staticshock> i'm still failing =/

[12:42:02] <pombreda> staticshock: ok, what do you have registered at pypi at the moment?

[12:42:15] <staticshock> https://pypi.python.org/pypi/colored-traceback

[12:42:30] <pombreda> and no colored_traceback at all ?

[12:42:45] <staticshock> not that i know of. i deleted it, i don't see it.

[12:43:26] <staticshock> yeah, i bet you're right. it's probably cached somewhere on register, and the cache doesn't invalidate sufficiently often

[12:46:52] <pombreda> this works at least pip install https://pypi.python.org/packages/source/c/colored-traceback/colored-traceback-0.1.0.tar.gz

[12:47:06] <pombreda> the pypi simple page seems to be confused though

[12:47:41] <staticshock> i guess i could file something with pypi if it's still a problem after a day

[12:47:52] <staticshock> is there anyone here who actually works on pypi?

[12:49:31] <pombreda> IMHO the issue that https://pypi.python.org/simple/colored-traceback or https://pypi.python.org/simple/colored_traceback may both still exist and trying to redirect in some kind of loop?

[12:50:15] <staticshock> yeah, possible. is there a way to "unregister" from the cli?

[12:50:38] <staticshock> i deleted it directly the pypi web interface, which may not be too robust, u guess

[12:50:42] <staticshock> *i guess

[13:02:27] <pombreda> worth a bug report :)

[13:05:32] <staticshock> already exists, looks like: https://bitbucket.org/pypa/pypi/issue/158/redirect-loops-are-generated-on-package

[13:10:15] <pombreda> staticshock: there you go :) you stumbled on a pesky one ;)

[13:11:53] <pombreda> staticshock: you wrote "yes, i will delete things at will to try to fix it. and no, you can't stop me" ... I cannot... but a bug did stop you ;)

[13:12:43] <pombreda> you could use now a "colorized-stacktrace" until this is fixed, so you can tinker

[13:13:40] <staticshock> nah, i'm alright. i'll just sit tight.

[13:14:05] <staticshock> i cloned pypi to see how hard it would be to fix, but i'm kind of disoriented in it

[13:15:53] <pombreda> this is not a trivial piece of infrastructure IMHO

[13:16:53] <staticshock> i'm trying to figure out how the register command is sent from distutils to pypi. there should be something on the receiving end. but what i'm seeing instead is register.py, which seems to define the client-side of it, and not the server side.

[13:16:53] <staticshock> weird

[13:17:36] <staticshock> and rpc.py, which sounds like server-side definitions, makes no reference to a distutils "register"

[13:18:40] <staticshock> man, lots of unpythonic things here

[13:18:44] <staticshock> :)

[14:40:52] <pombreda> heck .. wheel cannot convert a tar.gz to wheel?

[14:48:49] <pombreda> well fair enough, as this is not an egg

[14:57:37] <pombreda> and pip wheel does it alright

[16:30:18] <Ivo_> pombreda: wheel is a compiled package, .tar.gz is a source package

[16:30:40] <Ivo_> wheel convert does compiled things -> compiled wheel

[18:28:46] <the8thbit> Ivo_: Hm, I uninstalled and reinstalled setuptools through pip (which seemed to work) but I'm still getting that error when I try to install other packages

[18:50:23] <the8thbit> ah, apperently the newest version of setup tools is broken?

[18:50:30] <the8thbit> http://superuser.com/questions/762800/attempting-to-bootstrap-and-getting-weird-errors

[18:51:30] <the8thbit> damnit

[18:51:37] <the8thbit> even with the older version

[18:51:42] <the8thbit> I still get the same error

[19:02:17] <the8thbit> huh

[19:02:36] <the8thbit> removing pip and installing from apt seems to have fixed the issue...