pmxbot IRC Log Viewer

[05:38:54] <ToBeReplaced> on fedora, python3-pip, is there a way to configure site-wide values in python-pip3 on fedora? ... RTD says /etc/pip.conf, but it doesn't seem to be honored

[05:39:27] <ToBeReplaced> it's pip 1.5.6 it seems (rtd says we are at 6.1.1?)

[05:41:59] <ToBeReplaced> andddd i spoke too soon; pip search uses --index, pip install uses --index-url; thus my index-url was not being picked up

[05:42:27] <ToBeReplaced> feels like a bug ;)

[05:43:01] <ronny> ToBeReplaced: pip 1.5 is ages old, easiest way to use something recent is probably making updated virtualenvs

[12:10:57] <sanctorum> Does anyone know why pip install 'django<1.7.0,>=1.3.0,>=1.6.7,>=1.5.0,<1.8.99,>=1.5.1,<1.9.0,>=1.5.5,<1.7.99,>=1.4.0' tries to install Django 1.8 even though it has <1.7.0?

[12:11:56] <mgedmin> what version of pip, sanctorum?

[12:12:12] <mgedmin> certain older versions interpreted ',' as an OR in some situations and there was much confusion

[12:12:50] <sanctorum> Ah, good question. It's pip 1.5.6

[12:12:56] <mgedmin> ancient!

[12:13:01] <sanctorum> haha good!

[12:13:42] <mgedmin> btw I'm not 100% sure the change was in pip; could've been in setuptools; I just remember all the breakage in zope buildbots when the behaviour changed to consistently treat , as AND

[12:14:40] <sanctorum> Upgraded to latest pip and that fixes it. Thank you!

[12:14:53] <mgedmin> my recommendation: 'pip install --user virtualenv' and then create virtualenvs for each project -- the latest virtualenv will install the latest pip in each new virtualenv

[12:15:22] <ronny> nope

[12:15:32] <ronny> latest virtualenv just ships a very recent version

[12:16:00] <ronny> for getting the very last version a pip install -U pip setuptools might be needed

[12:16:24] <ionelmc> it's usually kept in sync with pip

[12:16:31] <ionelmc> not so with setuptools :|

[15:38:58] <frewsxcv> anyone know what happened with https://pypi.python.org/pypi/feedparser/5.2.0 ?

[15:39:17] <frewsxcv> version is technically 5.2.0.post1, post url and title would suggest it is 5.2.0

[15:45:08] <ionelmc> frewsxcv: afaik, post releases compare as equal

[15:45:56] <ionelmc> frewsxcv: http://legacy.python.org/dev/peps/pep-0440/#post-releases

[15:47:09] <frewsxcv> ah, thanks ionelmc

[17:45:07] <ronny> dstufft: btw, is there any chance to teach pip to check signatures

[17:45:29] <ronny> dstufft: also allowing asc uploads if possible (i imgine more than one maintainer wanting to sign)

[17:50:38] <ionelmc> ronny: have you seen that pip-like that verifies hashes?

[17:50:50] <ionelmc> pip-like tool*

[17:51:05] <ronny> ionelmc: nope, but hy hashes, signatures

[17:51:52] <ionelmc> oh

[17:51:54] <ionelmc> https://github.com/pypa/pip/issues/1035

[17:52:11] <dstufft> it's unlikely pip will check GPG signatures

[17:52:32] <dstufft> more likely is we get TUF implemented in PyPI and then pip

[17:53:20] <ronny> dstufft: TUF?

[17:53:52] <dstufft> PEP 458

[17:55:10] <ronny> dstufft: so that one will do signature checks and security checks?

[17:55:48] <dstufft> ronny: that is (most likely) how the Python ecosystem will implement package signing

[19:09:42] <jwhite007> "mkvirtualenv - -python=/path/to/python3" is not working for me anymore.

[19:10:10] <jwhite007> ImportError: dlopen(/usr/local/lib/python2.7/site-packages/_posixsubprocess.so, 2): Symbol not found: _PyString_AsString

[19:10:10] <jwhite007> Referenced from: /usr/local/lib/python2.7/site-packages/_posixsubprocess.so

[19:10:10] <jwhite007> Expected in: flat namespace

[19:10:10] <jwhite007> in /usr/local/lib/python2.7/site-packages/_posixsubprocess.so

[20:01:39] <magesing> Hi everyone, I'm trying to install matplotlib from inside a python 3.4 virtualenv. It complains that it can't find libpng even though I have libpng v 1.2.49 installed on my system (CentOS 6.6). How can I point pip at my system libpng?

[20:06:26] <apollo13> magesing: libpng is not enough, you need the dev headers etc…

[20:08:11] <magesing> apollo13: thanks, installing libpng-devel, and trying again

[20:08:49] <magesing> apollo13: thanks a bunch, that worked like a charm

[20:45:23] <[Tritium]> worth asking here...

[20:45:24] <[Tritium]> <nanonyme> Why oh why haven't we still have managed to nuke easy_install from orbit?

[20:46:08] <nanonyme> [Tritium], I got the impression people who owned setuptools were not the same people who run PyPA

[20:47:10] <[Tritium]> nanonyme: i thought they were...if they werent, they talk on the same mailing list and manage the ecosystem together

[21:00:33] <apollo13> nanonyme, [Tritium]: see the setuptools issue tracker, I asked that there :)

[21:00:50] <nanonyme> apollo13, can you link it up?

[21:01:51] <apollo13> lazy you, I have to search for it like you^^ https://bitbucket.org/pypa/setuptools/issue/17/remove-easy_install

[21:02:48] <nanonyme> apollo13, oh, I assumed it was in your favourites or you had a link to it through your profile

[21:02:55] <apollo13> na

[21:11:14] <apollo13> lol, got a mail that someone answered on the issue but nothing to see on the issue page^^

[21:24:10] <nanonyme> I've been writing for last 20 minutes

[21:25:49] <ronny> there was a complaint, i approvedand answered

[21:28:44] <apollo13> oh comments have to get approved? that is interesting :þ

[21:30:15] <ronny> apollo13: spam detection kicked in

[21:33:03] <nanonyme> I guess it didn't hit kick in mine?

[21:33:29] <apollo13> I think it did

[21:33:34] <nanonyme> Oh, hrm

[21:33:41] <apollo13> at least I got the email before it showed the comment on the page

[21:33:44] <apollo13> or caching, who knows

[21:35:16] <nanonyme> ronny, how does setup.py test depend on easy_install? Test dependencies or what?

[21:35:51] <ronny> nanonyme: setup requires, test requires and install_requires go to .eggs as egg install to facilitate that functionality

[21:37:08] <apollo13> ronny: well so that would be something to fix :þ

[21:37:19] <nanonyme> ronny, okay, right, it would take a lot of effort to change that but wouldn't wheel technically work for that too?

[21:37:19] <apollo13> also tox :þ

[21:37:53] <ronny> nanonyme: wheel is not importable, its a install only format atm

[21:38:06] <ionelmc> well

[21:38:08] <ronny> apollo13: tox solves a different problemset and is in part orthogonal

[21:38:23] <ionelmc> unless you zipimport it using dirty tricks

[21:38:39] <ronny> nanonyme: it is possible to import wheels, but distribution metadata from inside them wont work

[21:38:47] <tos9> presumably he means tox solves the "same problem" as setup.py test

[21:38:52] <nanonyme> ionelmc, would it be more dirty than what happens when you use eggs?

[21:38:53] <tos9> which is partially true

[21:39:18] <ionelmc> nanonyme: way more dirty

[21:39:26] <nanonyme> Seems like a design flaw to me...

[21:39:48] <ionelmc> nanonyme: they weren't designed for setup.py test, wheels are distribution format

[21:40:02] <ionelmc> just use tox :)

[21:40:23] <ionelmc> i don't understand why people insist using `setup.py test` today

[21:40:29] <apollo13> me neither

[21:40:30] <ionelmc> when we have tox

[21:40:33] <ionelmc> and virtualenvs

[21:40:40] <tos9> well yeah it should be deprecated but so should the other 3/4 of setuptools

[21:40:48] <apollo13> also install_requires is something which won't work for wheels

[21:40:53] <ronny> ionelmc: becasue its working directly

[21:41:19] <ionelmc> yeah it's working but it's messy

[21:41:20] <ronny> hmm, everybody here screaming about deprecation, - do you havea consistent story the users and downstreams can switch to now?

[21:41:43] <ionelmc> ronny: where is the tox story lacking?

[21:41:45] <tos9> ronny: For some things we do sure

[21:42:13] <ronny> ionelmc: you need at least 2 tools installed in fitting versions

[21:42:30] <ronny> tos9: but not for all, and they arent switched?

[21:42:39] <ionelmc> ronny: ok, `tox` and ?

[21:42:44] <tos9> ronny: well yeah if you want my actual opinion I think we should abandon setuptools and start from scratch

[21:42:48] <tos9> ronny: It seems you share that opinion :)

[21:42:53] <ionelmc> cause if you get tox installed you get virtualenv installed

[21:42:54] <ronny> tos9: hence im writing gumby elf

[21:42:57] <tos9> Yes.

[21:43:08] <ronny> tos9: still setuptools iz dere

[21:43:12] <tos9> ronny: Yup :(

[21:43:22] <tos9> ronny: Which is why I think we'd do a service to people if we started deprecating things.

[21:43:23] <ronny> and it will be there another 10 years at least

[21:43:27] <ionelmc> ronny: so yes, you need pip/setuptoools to install tox, 2 tools - but is that so bad?

[21:43:40] <tos9> But since I'm not particularly inclined to help all I can do is complain mostly, so I try not to do that too much :P

[21:43:42] <ronny> ionelmc: virtualenvv is needed as well

[21:43:58] <ionelmc> i mean i'm asking cause i have no idea what are the painpoints for newbies

[21:44:11] <ionelmc> ronny: yeah but tox depends on virtualenv

[21:44:11] <ronny> tos9: all that ranting does is stealing energy from the people that actually deal with this shit

[21:44:32] <tos9> ronny: I don't think that's true (and I don't think I rant, I was being self-deprecating).

[21:44:43] <tos9> I know you are one of such people so apologies if it did so to you, wasn't intended

[21:44:49] <apollo13> hihi, what did I start there

[21:44:57] <tos9> BUt I think everyone who's said "hey get rid of that" here so far has sounded fairly rational

[21:45:11] <ronny> tos9: so write proposals, educate downstreams, get people rolling on wheels and let them run down eggs till theybreak

[21:45:30] <ronny> but deprecating things in setuptools is a icky story

[21:45:37] <nanonyme> ronny, downstream goes on the path of least effort, they will not change from eggs and .exe's just because you tell them wheel be good

[21:45:49] <ronny> in particular enterprise distros take a big streaming shit in your garden ^^

[21:45:52] <ionelmc> so... is it a matter of just educating people?

[21:46:07] <tos9> ronny: Sure I don't think it would *ever* happen, it's totally pie in the sky. The amount of convincing to get people to let go of *just* setup.py test would be amazing. Forget about easy_install.

[21:46:30] <tos9> Which is pretty much why abandoning setuptools seems to be the right thing heh.

[21:46:32] <ronny> ionelmc: if everybody ranting about setuptools needign to deprecate X just start reporting issues, like "no wheel distribution'

[21:46:32] <nanonyme> In case you guys noticed, lxml latest build no longer has wheels and is as such now only installable without a compiler by easy_install, not by pip

[21:46:48] <ronny> nanonyme: so report a bug

[21:47:02] <nanonyme> ronny, I don't think it's a bug, it's maintainers managing maintenance effort

[21:47:05] <apollo13> who needs wheels if you have .tar.gz :)

[21:47:13] <nanonyme> ronny, and the outcome is pip is losing

[21:47:24] <tdsmith> fwiw homebrew goes to some trouble to avoid invoking easy_install as a side effect because we don't want installs to hit the network when we aren't expecting it and it's pretty hard to do

[21:47:38] <apollo13> nanonyme: if there is a tar.gz I can build my own wheels, always had to do that for lxml anyways, I do not see a diff there…

[21:48:01] <ronny> tdsmith: my next item for setuptools is env and setup call based opt-out from easy_install sideeffects

[21:48:06] <nanonyme> apollo13, well, the only platform where having any other distribution format than tarballs is Windows anyway

[21:48:23] <nanonyme> Erm, where it makes sense even

[21:48:25] <apollo13> nanonyme: no, I deploy everything via wheels here

[21:48:27] <tdsmith> ronny: awesome :)

[21:48:34] <ionelmc> ronny: if there would just be an repo that has all the wheels

[21:48:44] <nanonyme> apollo13, me too, locally. But I was more talking of PyPI

[21:48:48] <ionelmc> and you'd stick that into extra-index-url

[21:49:11] <ronny> ionelmc: a plan i have witha friend if mine is to kill virtualenv and just have a script generator that takes multi version things from a unpacked wheel repository

[21:49:31] <ionelmc> ronny: pundler?

[21:49:34] <ronny> nope

[21:49:49] <ionelmc> what's different from pundler?

[21:50:14] <nanonyme> ionelmc, would that involve an autobuilder or a person trying to keep track of releases so they can build wheels?

[21:50:23] <ionelmc> yeah

[21:50:39] <nanonyme> I meant, which one? :)

[21:50:39] <ronny> ionelmc: meta importation controll, environment controll, script generation controll will be completely different

[21:50:45] <ionelmc> it's already done, but hard to use : http://www.lfd.uci.edu/~gohlke/pythonlibs/

[21:50:55] <ionelmc> nanonyme: ^

[21:50:56] <ronny> ionelmc: and it will support conda ^^

[21:51:08] <ionelmc> wooot

[21:51:11] <ionelmc> meta import?

[21:51:15] <ionelmc> like a custom importer?

[21:51:29] <ronny> yes, having 300 wheels on sys.path will kill you

[21:51:52] <ronny> so instead a script toplevel map that willbe isntalled in some way

[21:51:55] <ionelmc> sounds very interesting

[21:52:05] <ionelmc> ronny: what python versions could run this?

[21:52:12] <ionelmc> is it feasible on 2.7?

[21:52:20] <ronny> ionelmc: technically any

[21:52:39] <ronny> ionelmc: target is likely 2.7 and 3.3+

[21:53:04] <ronny> ionelmc: but dot have high hopes yet, unless we manage to make a prototype its all just a pipedream

[21:53:10] <ionelmc> ronny: custom install tools?

[21:53:26] <ionelmc> or reusing pip/something?

[21:53:28] <nanonyme> ionelmc, if you also had project links from PyPI to there so company-internal PyPI mirrors would automatically pull packages from there, I'd be impressed. But that would most likely be stepping on maintainers' toes

[21:53:42] <ronny> ionelmc: semi, reuse of pip pip wheel, just unpacking them and creating hook mechanisms for scripts in a different way

[21:54:06] <ionelmc> nanonyme: it would work with extra-index-url

[21:54:33] <nanonyme> ionelmc, but wouldn't you need to own the project to set it? Or where would this extra-index-url be?

[21:54:34] <ionelmc> nanonyme: but it needs to be https, that's the problem with http://www.lfd.uci.edu/~gohlke/pythonlibs/

[21:54:48] <ionelmc> nanonyme: extra-index-url goes in pip.conf

[21:55:38] <nanonyme> ionelmc, I thought these days you could get pretty well-behaving SSL certs for free

[21:55:53] <ionelmc> and god damn it, binstar offers free hosting for pypi-style indexes

[21:56:13] <ionelmc> nanonyme: yeah, i wrote the guy a mail about this

[21:56:36] <ionelmc> no response yet :|

[21:58:01] <nanonyme> Right

[21:58:31] <ronny> gn8

[21:58:36] <nanonyme> Night

[23:13:24] <ToBeReplaced> is there a way to check gpg signatures for `pip install package-i-might-not-trust`

[23:15:09] <dstufft> No

[23:15:29] <dstufft> GPG does not have a sufficient trust model for package signing

[23:28:38] <ToBeReplaced> dstufft: can I PM to not clog up channel? i'm wondering what preferred method is -- all pip appears to give me is TLS and gpg seems good enough for debian?

[23:36:42] <dstufft> ToBeReplaced: I wrote some stuff here: https://caremad.io/2013/07/packaging-signing-not-holy-grail/

[23:36:57] <dstufft> ToBeReplaced: the tl;dr is that pip and PyPI's trust needs are more complex than Debian's

[23:37:18] <ToBeReplaced> dstufft: thanks

[23:39:06] <ToBeReplaced> dstufft: oh... so, we are setting up a private repository -- so we can actually install the public key / validate against IPA, which alleviates your concerns i think?

[23:40:19] <dstufft> ToBeReplaced: If you can trust everyone who can publish a package to that repo to not publish to the wrong name, yes that would be OK, but that's not good enough to get added to pip since the solution we come up with for PyPI will work for that situation too

[23:42:02] <ToBeReplaced> okay; short story is, today, for a private repo, i should just use TLS on installation side and do validation on the deploy side?

[23:52:15] <carljm> ToBeReplaced: I'm not sure what you mean by "deploy side" - do you mean the "upload a package to the index" side? It's hard to say anything sensible without knowing the trust needs of your private repo (who can publish to it? do your users implicitly trust all authors who are able to publish to it?). if the answer to the latter is "yes", then TLS and appropriate publication controls should be just fine.

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 20th of April, 2015