Log file Viewer

[08:48:44] <wiggy> pip install --only-binary wheel <package> is still download .tar.gz files for me

[08:48:49] <wiggy> that shouldn't happen, should it ?

[08:51:30] <wiggy> ah, format_control does not control the format - it controls the packages

[08:55:49] <[Tritium]> feature request: have pip complain if it detects it is being run as root.

[08:56:34] <[Tritium]> dont break, dont halt, dont error... just... admonish in a non-disableable way

[11:06:46] <ionelmc> [Tritium]: even when root and in a virtualenv?

[12:18:23] <rnix> does some kind of rollback exists for pip if upgrading package fails?

[13:11:28] <apollo13> rnix: afaik no

[13:14:36] <rnix> hm. would be good referring reliability...

[13:14:39] <rnix> but thx

[14:06:09] <apollo13> rnix: that is what venvs are for? :D

[14:51:08] <rnix> apollo13: yes and no ;)

[14:52:16] <rnix> apollo13: e.g. Application with TTW updates.

[14:52:25] <apollo13> whatever TTW is

[14:52:31] <rnix> through the web

[14:52:34] <apollo13> lol

[14:53:58] <rnix> well, there's room for this kind of stuff

[14:55:15] <apollo13> yeah, create new relocatable venv and then move the old out of the way…

[14:55:24] <apollo13> or take an lvm snapshot or whatever

[14:55:31] <apollo13> filesystems are not exactly atomic either way ;)

[14:57:06] <rnix> relocatable venv was my first thought as well. but it feels cumbersome compared to a build-in rollback

[14:58:15] <rnix> lvm snapshot sounds interesting

[15:09:48] <rnix> apollo13: https://dh-virtualenv.readthedocs.io/en/latest/ this one looks promising either, though OS bound

[15:49:52] <kboers> Hello! Can anyone confirm that later versions of virtualenv do NOT create the virtualenv-2.7 bin script?

[15:55:22] <kboers> Looking through the history for setup.py, hoping to see the entry points changes over time, but no such luck. Maybe it was a distro thing? Some version of 2.7.3 that I brew installed might have done it, and not virtualenv

[16:58:53] <kboers> Yeah, nevermind, seems like it’s a distro thing. Brew has done it, and yum does it

[17:02:58] <tdsmith> homebrew doesn't ship virtualenv

[17:03:30] <tdsmith> so if you're seeing it on top of a homebrew installation the package must have done it

[17:04:27] <dstufft> virtualenv doesn't ship -X.Y scripts anymore

[17:10:18] <kboers> Thanks, folks!

[18:30:44] <rangerpb> hey folks, suppose i wanted to use setuptools' entry_point function, but I dont want every entry_point to end up in /usr/bin. Anyone think of a way I could do?

[18:31:02] <rangerpb> or perhaps mimic entry_point another way and just install the result elsewhere?

[18:34:06] <daniel_holth> What are you packaging? Sbin?

[18:35:46] <rangerpb> actually working on cloud-init

[18:35:53] <harlowja> cloud-init is the best

[18:35:54] <harlowja> lol

[18:36:32] <rangerpb> which had one entry_point for cloud-init ... but we added another one and don't want to flood /usr/bin but do love the upside the entry_point provides including taking care of the python version etc

[19:11:53] <dstufft> rangerpb: Hmm, I don't think that there's aything like that no

[19:12:17] <dstufft> rangerpb: are you not expecting end users to invoke these?

[19:15:15] <rangerpb> dstufft, correct, this is something other system commands would execute

[19:17:00] <dstufft> rangerpb: yea I don't think there's anything like that :/ The cloest I could think of is sys.executable -m path.to.a.module.instead.of.a.command.on.disk but that assumes that it's cloud-init executing these and not some other system

[20:04:03] <[Tritium]> ionelmc: yes - even when root and virtualenv

[20:24:05] <ionelmc> [Tritium]: wouldn't you have it say something like "warning: don't use root, use a virtualenv instead" ? :-)

[20:25:16] <ionelmc> the warning needs to tell the user an alternative, besides the not always doable "don't use root"

[20:26:04] <[Tritium]> ionelmc: let me just put a package on pypi that does shutil.rmtree('/') in setup.py and I'll get back to you...

[20:28:05] <Wooble> to be fair, I'd be just as annoyed if a package installing as me deleted ~

[20:29:50] <Wooble> granted I'm not the only person who uses my machine at home.

[20:29:52] <ionelmc> [Tritium]: getting users for that won't be easy

[20:30:07] <ionelmc> you may get lucky on hackernews

[20:30:09] <ionelmc> give it a try lol

[20:30:42] <[Tritium]> Well, if some of the -sig users get their way, i can get the name of a popular package!

[20:33:50] <dstufft> [Tritium]: that isn't going to happen in anything even remotely resembling an automated process, and ideally not at all

[20:34:23] <[Tritium]> oh thank god

[20:34:27] <dstufft> I don't think that shutil.rmtree in setup.py is that big of a deal, because once you're executing code from someone else it's basically impossible to protect yourself from them being malicious

[20:34:39] <dstufft> even if you're not running as root

[20:34:59] <dstufft> (https://xkcd.com/1200/)

[20:35:39] <ionelmc> hahah

[20:35:47] <[Tritium]> True!

[20:36:07] <apollo13> now if people would just use selinux

[20:36:25] <[Tritium]> but pip should still be annoying to people running as root for very practical reasons

[20:38:36] <dstufft> [Tritium]: I'm down with directing people away from root for cases of modifying a system managed Python

[20:38:46] <dstufft> I don't think it makes sense to do it inside of say, a virtual environment

[20:39:11] <[Tritium]> ayw

[20:39:12] <[Tritium]> aye