Log file Viewer

[03:59:29] <mathu> the latest pip version marked stable on gentoo is 1.5.6. does anybody know why no more recent versions are marked stable?

[04:04:57] <mathu> also i'm getting permission denied when i'm trying to /uninstall/ a package: PermissionError: [Errno 13] Permission denied: '/tmp/pip-m_6931-uninstall/usr/lib64/python3.3/site-packages/urwid'

[04:12:58] <mathu> is there a way to configure pip to not use /tmp as a tmp directory, instead using somewhere in my home directory? using sudo with pip on gentoo is bad

[04:15:17] <mathu> also to install to somewhere other than /usr/lib64/...

[04:20:10] <twm> mathu: There is the --user flag.

[04:20:36] <twm> I haven't tried, but it likely obeys the TMP or TMPDIR or whatever it's called environment variable.

[04:23:08] <mathu> neither of those sound very permanent haha

[04:23:11] <mathu> i'll keep them in mind though

[04:23:14] <mathu> thanks!

[09:00:28] <koobs> hmm

[09:00:31] <koobs> here you all are

[09:00:33] <koobs> anyone awake?

[15:51:53] <mathu> how would i go about completely purging pip from my system? can i simply uninstall pip through my package manager and then delete the packages installed via pip from my site-packages folder?

[15:52:21] <ronny> mathu: that would be one way to do it

[15:52:47] <mathu> (i get permission denied errors when i uninstall pip packages via pip, and running pip via sudo on gentoo is a bad thing)

[15:53:11] <mathu> (packages are in /usr/lib64/python.... so it makes sense that pip can't access them when run by my user account)

[15:53:34] <mathu> (i want to purge pip so that i might set up pip again in a way that's more gentoo-safe

[15:56:21] <tos9> mathu: you've got packages that were installed by your package manager then

[15:56:25] <tos9> (or that you previously installed with sudo)

[15:58:52] <mathu> tos9: correct on both counts haha

[15:59:07] <tos9> mathu: Then you need sudo to remove them :)

[15:59:22] <tos9> (I'd recommend removing the former with the former though)

[15:59:29] <mathu> tos9: yup, but using sudo is what got me in this mess in the first place haha

[15:59:40] <tos9> Sure :)

[15:59:41] <mathu> tos9: yeah, the python packages installed via portage are fine

[15:59:44] <Wooble> You can't fix messed made by root as non-root.

[16:00:07] <mathu> Wooble: well, i don't need to be non-root. i just need to not run pip as root

[16:00:24] <mathu> Wooble: i asked if i can uninstall pip and them rm them as root from the site-packages directory

[16:00:27] <tos9> You can run rm as root if that makes you feel better.

[16:00:31] <tos9> That's no better or worse really.

[16:00:46] <mathu> tos9: alright, cool. i was worried about residue elsewhere on the system somehow

[16:00:56] <tos9> mathu: Sure, there could be plenty of residue.

[16:00:58] <Wooble> well, except pip's probably smarter about what to uninstall then rm

[16:01:01] <tos9> (You'd have no real way of knowing though.)

[16:01:14] <mathu> well, asking on irc was my way to try to know haha

[16:01:27] <tos9> mathu: Oh, well we can't tell you that, programs can do whatever they want

[16:01:34] <tos9> And programs with root can do so wherever they want

[16:01:44] <mathu> Wooble: the problem with pip + sudo on gentoo is strange and i don't understand it. but the end result was a corrupted python-exec script that caused many other python utilities to be evaluated as pip commands

[16:02:15] <mathu> Wooble: which, i don't want. so while pip better knows what to remove, for sure, i do not want to let it run as root again

[16:02:53] <mathu> tos9: i mean, someone with knowledge of how pip works could certainly tell me if i need to worry about residue and where i might find it :P

[16:02:53] <Wooble> It's not running pip as root that was your problem, it was the arbitrary setup scripts pip was also running as root. pip remove shouldn't have the same problems, but whatever, it's up to you.

[16:03:02] <tos9> mathu: pip just runs some python code

[16:03:10] <tos9> mathu: that python code can do whatever it wants.

[16:03:26] <mathu> tos9: are pip packages arbitrary python? i figured they would be packages in a more conventional sense

[16:03:48] <Wooble> setup.py is a python script. It can contain anything.

[16:03:59] <mathu> Wooble: that's comforting. i fixed the python-exec thing once, so if pip breaks me again then i'll just fix it again haha

[16:04:07] <tomprince> In this case, it is the fact that gentoo has /usr/bin/pip is a symlink, that got overwritten by 'sudo pip install -U pip', probably.

[16:04:08] <mathu> Wooble: ah, i see. i didn't know that

[16:05:05] <mathu> tomprince: i have run that exact command so that is probably what broke my system, haha. i don't see how that would break anything though

[16:05:18] <mathu> tomprince: would it not just point the symlink a newer version of pip?

[16:05:48] <mathu> (thank you for your help, everyone! i'm pretty ignorant of pip and python environments in general, and you've all been quite informative)

[16:06:14] <mathu> i guess the problem of pip breaking gentoo might be a question for #gentoo

[16:06:16] <tomprince> mathu: lrwxrwxrwx 1 root root 31 May 2 16:27 /usr/bin/pip -> ../lib/python-exec/python-exec2

[16:06:26] <mathu> tomprince: ohhh

[17:54:07] <_habnabit> will pip eventually disable the 'hey! upgrade pip!' message when you are, in fact, upgrading pip?

[17:54:18] <_habnabit> it's kind of annoying to get the message even when i'm doing `pip install -U pip`

[18:08:49] <dstufft> _habnabit: there's an issue for it yea, it's slightly non obvious about how to go about it though

[18:09:07] <dstufft> the waning is done at a higher level than we have access to what we're installing

[18:09:13] <_habnabit> dstufft, i figured

[18:09:24] <_habnabit> dstufft, just wondering if i was the only one, haha

[20:17:28] <nanonyme> dstufft, FWIW do you already sort requirements so pip and setuptools are upgraded as the first items?

[20:17:54] <nanonyme> Ah, I guess upgrading pip doesn't even help much. Setuptools might :)

[20:18:06] <nanonyme> (since pip can't self-upgrade and restart)

[20:37:55] <nolsen> I think pip broke: https://meldy.hira.io/Zerobin/?37467ca8153bd710#jwJGEh7GYCJzy2mIf4s1ERcTJiqcdponLl+gdRVRpVo=

[21:06:17] <dstufft> nolsen: it's a ubuntu/debian problem

[21:06:55] <dstufft> nolsen: they de-vendored stuff from inside of pip, you installed something that pip depended on that you then installed and incompatible version of

[21:27:24] <nibalizer> puppet currently determines if a package has an available upgrade using this bit of code https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb#L59 is that the right approach? should we be using some pip subcommand? (I couldn't find anything easy)

[21:37:07] <dstufft> nibalizer: well the JSON api is better than this

[21:37:20] <dstufft> for friendliness to PyPI anyways

[21:37:47] <dstufft> nibalizer: that's probably the best way in a way that has a programatic interface right now though

[21:40:19] <nibalizer> when we do the same for apt or whatever, we ask apt if an upgrade is available

[21:40:24] <nibalizer> is there a way to do that with pip?

[21:41:41] <nibalizer> I think that piece of code is ~4 years old and I'm in there anways for a different reason, so wondering what we /should/ be doing

[21:42:20] <dstufft> well, pip list --outdated will tell you if upgrades are available for _anything_

[21:42:36] <dstufft> it's not a guarenteed stable output format though

[21:43:14] <nibalizer> I'm also thinking there is a funky error state where a user has a pip.conf pointing to a local mirror, that is pinned or whatever, and puppet hits the real pypi and insists an upgrade is available, but then when pip tries to install it doesn't get that version

[21:43:42] <nibalizer> if the output format isn't gonna be stable I don't want to risk it

[21:47:10] <dstufft> there's a ticket to make the output format stable

[21:47:19] <dstufft> or rather, make a machine parseable output

[21:47:22] <dstufft> but nobody's done it yet

[21:47:38] <dstufft> nibalizer: at the list, checking https://pypi.python.org/pypi/<foo>/json would be better for PyPI fwiw

[21:59:17] <nibalizer> dstufft: okay, thanks for your help

[21:59:31] <dstufft> it'd also be faster

[21:59:39] <dstufft> the JSON API can be cached in Fastly

[21:59:41] <nibalizer> im fairly confident we can make that happen

[21:59:43] <dstufft> XMLRPC always goes back to the origins

[21:59:52] <dstufft> also more fault tolerant

[21:59:58] <nibalizer> https://github.com/puppetlabs/puppet/pull/3984/files is my PR for semirelated things btw

[22:00:11] <nibalizer> with some 'what goes in puppet3 and what goes in puppet4' on the side

[22:01:33] <dstufft> nibalizer: fwiw, if someone wants to contribute to pip to make it better to use pip from CM, we'd certainly work with anyone who cares about it and wants to do it, and merge things and what not. That's mostly gated on someone who cares making the time vs us not being willing to accept that. (Not that you need to do it either, just an FYI if you want to make something that's "more" correct)

[22:02:04] <nibalizer> i think the future is gonna be pretty cool

[22:02:33] <nibalizer> because the prevailing winds in puppet at least are to move stuff like pip handling out of 'core' and into a separate repo/gem/module thing that can move faster and be overseen by subject matter experts

[22:02:49] <dstufft> awesome :)

[22:03:10] <dstufft> I've never used puppet specifically, I've used chef and salt though ;)

[22:03:34] <nibalizer> the practical implication of that being that probably us (openstackish) hackers can fix stuff over here in pip and over here in the puppet-pip stuff and the world just starts to look better

[22:03:38] <dstufft> (I'm not a real ops person, so I just let real ops people make choices)

[22:05:03] <nibalizer> okay, ill see if I can get the version checking to json in place

[22:05:18] <nibalizer> ill roll the idea of making changes to pip around in my head, maybe discuss it with some folsk

[22:05:46] <nibalizer> thanks again

[22:06:09] <dstufft> nibalizer: no problem! Let me know if you need any other help