pmxbot IRC Log Viewer

[00:31:56] <_Dejavu> Hello, kind folks, does anyone have problems uploading to pypi ? I get >> Server response (200): Output Follows

[12:03:05] <mgedmin> pip install zc.recipe.egg => UnsupportedWheel: zc.recipe.egg is in an unsupported or invalid wheel

[12:03:27] <mgedmin> the wheel was generated with python setup.py bdist_wheel

[12:03:38] <mgedmin> it looks okay-ish if I unzip and peek inside

[12:03:40] <mgedmin> what could be the problem?

[12:04:29] <mgedmin> could it be that pip sees the '.egg' in the name and assumes this is not a wheel?

[12:07:40] <dstufft> mgedmin: looking

[12:08:44] <mgedmin> full traceback: https://github.com/buildout/buildout/issues/267#issuecomment-145835161

[12:08:49] <dstufft> heh

[12:08:57] <dstufft> I think setuptools sees the .egg and thinks it's an egg

[12:09:24] <dstufft> we ask setuptools to give us the WHEEL file from it

[12:09:28] <dstufft> and this error is raised: https://bpaste.net/show/b97fe7e3706f

[12:10:30] <mgedmin> huh, that's not the traceback I'm seeing

[12:11:40] <mgedmin> ah, because there's a bare except: in def wheel_version() ?

[12:11:59] <dstufft> mgedmin: yea, I dropped a raise there

[12:12:08] <mgedmin> oh my

[12:12:09] <dstufft> to reraise the exception

[12:12:26] <mgedmin> the unzipped wheel indeed has a 'zc.recipe.egg' directory >.<

[12:13:23] <xafer> cute

[12:14:57] <dstufft> mgedmin: my sense is that this is probably a setuptools bug... but it might be our fault too

[12:18:57] <mgedmin> should I file a pip bug or ... ?

[12:20:06] <dstufft> mgedmin: wouldn't hurt to file a pip bug and a setuptools bug

[12:20:49] <mgedmin> oh look, somebody already filed a bug https://github.com/pypa/pip/issues/3028

[12:21:24] <mgedmin> a while ago

[12:21:31] <mgedmin> I wonder how they got it? builtin wheel caching?

[12:22:27] <dstufft> mgedmin: given they say it's limited to 7.x, probably yea.

[12:28:01] <mgedmin> ha ha removing the built universal wheel from pypi doesn't help

[12:28:11] <mgedmin> pip install builds a wheel locally and then fails with the same error

[12:28:20] <mgedmin> even on 1st install

[12:29:21] <dstufft> mgedmin: you'd need to modify your setup.py so that bdist_wheel raises an error

[12:29:49] <dstufft> that'll force pip to fall back to setup.py install

[12:31:39] <mgedmin> is it a coincidence that this bug showed up right after we enabled universal wheel building? hmm

[12:37:08] <mgedmin> BTW I suggest retitling https://github.com/pypa/pip/issues/3028 "pip install zc.recipe.egg fails on pip >= 7.x"

[12:37:14] <mgedmin> it's not windows-specific

[13:33:52] <BlueAidan> I'm trying to build a pypy-specific version of a package and a cpython version using bdist_wheel

[13:34:11] <BlueAidan> I used python setup.py bdist_wheel --python-tag pp

[13:34:19] <BlueAidan> and python setup.py bdist_wheel --python-tag py2

[13:34:37] <BlueAidan> but pip is still always trying to install the cpython 2.7 version

[13:34:42] <BlueAidan> ah, it needs to be cp

[13:39:10] <BlueAidan> hmm; that results in pip not finding any viable versions to install on pypy

[13:44:55] <ionelmc> BlueAidan: maybe there's some issue with wheel tags on pypy

[13:45:08] <ionelmc> search the wheel/pip/setuptools bugtrackers for it

[13:45:48] <dstufft> think you need pp26

[13:45:51] <dstufft> or pp27

[13:45:54] <dstufft> something like that

[13:54:03] <BlueAidan> looks like cp2 and pp2 worked

[13:54:40] <BlueAidan> needed to be able to specify psycopg2-cffi on pypy and psycopg2 on cpython

[14:10:42] <tdsmith> dstufft: i'm sure you're aware but i think the pypa issue tracker probably likes the idea of deprecating the invocation of pip's scripts much better than the python community as a whole will :p

[14:12:05] <tdsmith> i'll land https://github.com/Homebrew/homebrew/pull/44667 and see if anyone notices

[14:17:15] <dstufft> tdsmith: Yea, I mean IDK the right answer here :(

[14:17:19] <dstufft> the current situation sucks

[14:26:20] <Ivo> dstufft: I think noticing something exists and actually asking is the best solution

[14:27:15] <Ivo> distro package managers have it easy because they force themselves to be the singular package manager you're allowed on your OS

[14:27:44] <Ivo> you can be running debian wheezy and debian jessie on exactly the same box on the same kernel in the same userspace

[14:28:09] <Ivo> But with python (...and many other programming languages), you can!

[14:30:59] <Ivo> ***you can't be running

[14:43:57] <dstufft> tdsmith: "why not pip2 and pip3", this is a preview of what proposing this to the greater public is going to be like I bet

[14:55:29] <Muchoz> When pip says a clone repo already exists and asks you to ignore, switch, wipe or backup it. Is there a way to automatically reply to this from the cli?

[14:58:55] <tdsmith> if there isn't, you could pipe in an answer with `yes`

[14:59:46] <dstufft> Muchoz: --exists-action

[14:59:51] <dstufft> I think is the thing

[15:00:15] <Muchoz> dstufft, thank you!

[15:00:41] <tdsmith> dstufft: idk that i have a good answer for xu-cheng tbh; having a pip2 in PATH that isn't ours when our python is in PATH seems a little exotic

[15:01:34] <dstufft> tdsmith: you mean like the one you get if you do python -m ensurepip on stock OS X Python in El Capitan and the latest update to Yosmite?

[15:02:00] <tdsmith> where's that install?

[15:02:35] <dstufft> tdsmith: /usr/bin/local/pip2

[15:02:44] <tdsmith> ffff

[15:04:04] <tdsmith> using ensurepip with system python probably still qualifies as exotic but probably not for long ;p

[15:04:29] <tdsmith> good example, thanks

[15:05:13] <dstufft> tdsmith: np!

[15:06:00] <dstufft> tdsmith: it's not a great situation, I can't think of a good way to generically handle this within the script wrappers themselves that isn't just a time bomb

[15:08:14] <Ivo> whats el capitan python version?

[15:08:29] <tdsmith> 2.7.10

[15:08:46] <dstufft> same with latest update to Yosmite

[15:08:48] <Ivo> I could've sworn they said they weren't touching their python anymore

[15:08:48] <dstufft> Yosemite

[15:08:54] <tdsmith> yosemite's 2.7.10 still has setuptools 1.something

[15:09:03] <tdsmith> which is an upgrade from 0.6 but

[15:09:15] <tdsmith> it's remarkable that things still work so well

[15:09:19] <Ivo> after they told... hynek? That they were going to leave their hack on python/openssl in forever

[15:10:07] <Ivo> what are they doing with the openssl that python uses then?

[15:10:10] <dstufft> https://caremad.io/s/RaAj3HdRbq/

[15:10:20] <dstufft> that's what ships with El Capitan

[15:10:31] <tdsmith> el cap still ships the openssl libraries

[15:10:44] <Ivo> what ver tho

[15:10:58] <Ivo> they just stuck numpy 1.8 in there for funzies?

[15:11:05] <dstufft> Ivo: look for the .egg-info's to see versions

[15:11:17] <dstufft> the sad thing is with SIP we can't uninstall them

[15:11:18] <Ivo> WTF

[15:11:21] <dstufft> or upgrade them

[15:11:33] <Ivo> this is painful to look at

[15:11:34] <dstufft> and they put this dir ahead of site-packages in sys.path

[15:11:41] <Ivo> I wish they'd just kill it

[15:11:42] <dstufft> I'm talking to apple about that though

[15:11:52] <dstufft> so we'll see what they'll do

[15:12:04] <Ivo> it's like they have an intern experimenting with stuff except he/she's experimenting with what they ship

[15:12:35] <d0p> guys gotta problem

[15:12:37] <Ivo> do they actually have tools using all this stuff?

[15:12:54] <d0p> I use some package that i dont know the name of

[15:12:57] <d0p> it

[15:13:15] <Ivo> what do you import it as

[15:13:19] <d0p> import facebook

[15:13:55] <Ivo> d0p: if you have pip in your current python environment you can run pip list

[15:14:08] <d0p> I do

[15:14:13] <d0p> but there is no package named facebook

[15:14:16] <d0p> thats whY I ask

[15:14:26] <Ivo> d0p: can you pastie them

[15:14:37] <d0p> http://ix.io/le4

[15:15:56] <Ivo> d0p: do

[15:16:10] <Ivo> import facebook, sys; print(sys.modules['facebook'])

[15:16:53] <d0p> I can not import it

[15:16:55] <d0p> lol

[15:17:07] <d0p> but i have it in my script

[15:17:10] <d0p> [16:55:48] n1c:redditFacebookBot git:(master*) $ cat main.py

[15:17:12] <d0p> import praw

[15:17:14] <d0p> import facebook

[15:17:16] <d0p> import urllib

[15:17:41] <Ivo> d0p: you did not `pip list` the packages from your environment that your script is running in

[15:17:55] <Ivo> lol https://pypi.python.org/pypi/Facebook/ well thats a great package

[15:18:26] <d0p> ivo it is facebook-sdk for py got it :)

[15:19:46] <Ivo> dstufft: you know what openssl el capitan is shipping with now?

[15:21:03] <gthank> OpenSSL 0.9.8zg 14 July 2015

[15:21:09] <dstufft> $ /usr/bin/openssl version

[15:21:09] <dstufft> OpenSSL 0.9.8zg 14 July 2015

[15:21:10] <dstufft> er

[15:21:11] <dstufft> yea

[15:21:14] <gthank> I was up-to-date on cap as of yesterday

[15:21:34] <gthank> Heh, sorry, dstufft

[15:29:25] <dstufft> "Yes, I have pulled the bugs into an upcoming release for one of the engineers on my team to look at. I’m out of town right now, so I don’t have current status, but I’ll get in contact if there is something that can be done on your end as well to help with the situation. " /cc tdsmith Ivo (Just got that from Apple)

[15:29:38] <tdsmith> oh hot

[15:40:19] <Ivo> hope there isnt some critical system tool that needs matplotlib and six in their system python

[16:33:32] <elarson> I'm trying to install a package from the filesystem in jenkins. I can pip install -r my-reqs.txt and everything works with `-e path-to-package` in the requirements.txt but when ci runs, it can't find the directory, even though I can log into the workspace and see it

[16:36:13] <dstufft> elarson: -e might be relative to the current dir, not the requirements.txt

[16:40:19] <elarson> hmm... it should be the same but maybe it isn't

[16:49:14] <jwhite007> i'm having trouble doing a pip install of numpy… "ImportError: libblas.so: cannot open shared object file: No such file or directory" upon issuing "locate libblas.so", i get "/usr/lib64/libblas.so.3"

[17:28:59] <Ivo> why does github md make -----------

[17:29:02] <Ivo> dissapear

[17:33:50] <jwhite007> i'm having trouble doing a pip install of numpy… "ImportError: http://libblas.so/: cannot open shared object file: No such file or directory" upon issuing "locate http://libblas.so/", i get "/usr/lib64/libblas.so.3"

[17:35:31] <tdsmith> i assume it doesn't actually say "http://libblas.so/" on your terminal

[17:35:53] <jwhite007> oops… bad copy.

[17:36:33] <jwhite007> tdsmith: should read "locate libblas.so"

[17:36:45] <tdsmith> i figured

[17:37:58] <tdsmith> i don't have experience diagnosing dynamic linking issues on linux but i'm sure someone will comment

[17:38:35] <jwhite007> tdsmith: it really sucks not having admin rights for development.

[17:39:42] <tdsmith> i bet :/

[17:40:58] <jwhite007> tdsmith: IT here doesn't get the whole Dev-Test-Prod thing.

[17:41:32] <jwhite007> sure… don't give me admin on test and prod. that's fine.

[17:47:43] <Ivo> jwhite007: libblas.so isn't libblas.so.3

[17:48:14] <jwhite007> Ivo: i thought it might be another version.

[17:48:24] <Ivo> jwhite007: you probably need to set the locatino of your blas library in your ENV while installing numpy

[17:48:36] <Ivo> I'm not sure of specifics with numpy

[17:48:43] <Ivo> people in #numpy might be able to help more

[17:48:52] <jwhite007> Ivo: thanks.

[17:49:36] <jwhite007> Ivo: looks like i first have to get libblas.so

[17:49:53] <jwhite007> Ivo: unfortunately i do not have root or sudo.

[17:49:59] <Ivo> jwhite007: what linux are you on

[17:50:11] <jwhite007> redhat enterprise

[17:50:20] <Ivo> jwhite007: https://www.scipy.org/scipylib/building/linux.html shows setting up the environemnt

[17:51:19] <jwhite007> Ivo: thanks.

[18:27:58] <elarson> are there any folks here reasonably well versed in dh-virtualenv?

[18:28:21] <elarson> looking at https://github.com/spotify/dh-virtualenv/issues/117

[18:35:01] <dmerejkowsky> quick question: i have a package that is python2 only on pypi

[18:35:12] <dmerejkowsky> how can I prevent it to be installable with pip3 ?

[18:36:30] <Wooble> dmerejkowsky: you could have setup.py check the python version and print an error message and exit?

[18:37:23] <dmerejkowsky> I was hoping there was a way to declare it in the setup.py attributes

[18:37:59] <Wooble> dmerejkowsky: well, there is, but it doesn't do anything, so don't bother :)

[18:38:16] <dmerejkowsky> ok thanks

[18:47:30] <Ivo> elarson: have you tried just taking out the -e

[18:48:19] <Ivo> dmerejkowsky: for the sdist distribution, its usually fine to have an if check in your setup.py

[18:49:02] <Ivo> dmerejkowsky: for the wheel distribution, you can create a setup.cfg and specify your compatability tag for the created wheel

[18:49:14] <Ivo> In this case I think you want python-tag=py2

[18:50:03] <Ivo> see here https://wheel.readthedocs.org/en/latest/#defining-the-python-version

[18:50:54] <dmerejkowsky> Ivo: thanks for the explanations

[18:50:55] <Ivo> you can also specify only python2 classifies as well,

[18:51:31] <Ivo> dmerejkowsky: highly encourage you to make it python2+3 compatible! :D

[18:52:11] <jessamynsmith> yay for tox to make that easier

[18:53:09] <elarson> Ivo: yeah

[18:53:28] <elarson> Ivo: it is actually failing b/c dh-virtualenv does a pip install -r requirements.txt which is fine

[18:53:34] <elarson> but then it does a pip install .

[18:54:18] <Ivo> if this is for distribution applications, not libraries

[18:54:20] <elarson> this is openstack so there is pbr, which includes requirements.txt in the setup.py

[18:54:28] <Ivo> yeah I hate that

[18:54:31] <Ivo> bad idea

[18:54:34] <elarson> yeah

[18:54:48] <Ivo> anyway, if dh-virtualenv is *only* for applications

[18:55:03] <elarson> Ivo: it is an application

[18:55:06] <Ivo> in which case - installing requirements through requirements.txt is fine and expected

[18:55:17] <Ivo> then it could do pip install . --no-deps instead

[18:55:30] <elarson> hmm... I'll look into that then

[18:55:40] <elarson> Ivo: thanks for the suggestion!

[18:55:52] <Ivo> If it's pbr'ed I'm not even sure if that will help though lol

[18:55:58] <Ivo> pbr might do its own thing anyway

[18:57:31] <elarson> it looks like dh-virtualenv has a skip-install flag that I can use to skip the pip install .

[19:40:19] <nedbat> reading newb code sometimes presents interesting puzzles: like a "boolean" used like this: if value != str(0):

[19:41:15] <nedbat> (sorry, meant for #python...)

[19:41:51] <Ivo> nedbat: did they come from C lol

[20:36:48] <agronholm> hey peeps, where is :python_version and the other conditionals documented?

[20:37:39] <dstufft> agronholm: lol

[20:38:09] <dstufft> agronholm: they aren't really :( there's some PEPs that mention them, and a new PEP that attempts to finally standardize them in a way that isn't tied to Metadata 2.0

[21:09:02] <Ergo> hey guys, when doing workshop, is there a way i can ensure that I can supply all the needed dependencies to people somehow? I have no idea if the network will be stable during the event

[21:10:00] <Ivo> Ergo: use pip wheel command for all packages you want, they go in a folder, zip folder up, distirbute to participants

[21:10:31] <Ergo> Ivo: but that will work only for one OS/arch right?

[21:10:54] <Ivo> Ergo: if the packages are pure python it will work for any

[21:11:18] <Ivo> you could also download the wheels / sdists off pypi if you want

[21:13:23] <Ivo> note that by default `pip wheel` will produce wheels only compatible with your python major version (2 or 3)

[21:13:42] <Ivo> many pure python packages' wheels on pypi might be 2 & 3 compatbile

[21:15:31] <nanonyme> Wasn't there some way to declare universal wheel?

[21:16:23] <Ergo> it will be only for python 3.x, I'll need to check if everything can run without c extensions :-)

[21:19:58] <offero> I'm noticing an issue with data files using pip 1.7

[21:20:26] <offero> In pip 1.5.6, data files are copied correctly, but using 1.7, then are not.

[21:20:43] <offero> pip install Scrapy==0.16.4 for instance

[21:20:50] <offero> Why would this be?

[21:40:30] <dstufft> offero: setuptools and distutils have different opinions on where data_files should go

[21:41:03] <dstufft> when installing from sdist, you get setuptools opinion, when installing from wheels you get distutils

[21:41:13] <dstufft> pip 7+ auto builds a wheel before installing anything

[21:41:38] <dstufft> Ergo: you could do pip install --download dirname --no-binary :all:

[21:41:44] <dstufft> that should download sdists for everything

[21:45:55] <offero> dstufft: thanks for that explanation.

[21:55:05] <Ergo> dstufft: thx :-)

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 6th of October, 2015