Log file Viewer

[10:35:39] <s1341> anyone with Mac expertise around to help me with issue #2160 ?

[10:36:20] <s1341> https://github.com/pypa/pip/issues/2160

[13:10:44] <Ivo> !logs

[13:10:44] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[14:52:20] <ionelmc> what was that secure dist upload tool again?

[14:52:53] <ionelmc> ah yes, twine

[15:14:19] <ionelmc> is there a way to exclude a file but just from the binary distrubutions?

[15:14:27] <ionelmc> when bdist_whatever

[16:41:59] <dshap> Hey all, is there any way to specify that something in my requirements.txt file for pip should always install from the latest package?

[16:42:07] <dshap> I’d like pytz to always install the latest

[16:45:56] <DanielHolth> you don't have to put a version in theree

[16:46:39] <dshap> DanielHolth: i tried just putting “pytz” on its own line, but when i run “pip install -r requirements.txt”, it says the requirement is already satisfied and it does not upgrade my pytz

[16:57:21] <dshap> think im just going to resort to adding a separate call to “pip install” to my deploy

[16:57:27] <dshap> first “pip install -r requirements.txt”

[16:57:30] <dshap> next “pip install -U pytz”

[16:57:35] <dshap> unless there’s a better way

[21:37:19] <nanonyme> dshap, something like pip install -U -r requirements.txt doesn't work?

[21:37:40] <dshap> nanonyme: it tries to upgrade everything on the file

[21:37:55] <dshap> nanonyme: i just want this functionality for one package

[21:38:34] <nanonyme> dstufft, ^ isn't that pretty terrible behaviour from pip that it tries to reinstall on just update if version matches already?

[21:38:53] <nanonyme> Rather have a separate reinstall flag

[21:43:43] <romanosaurius_re> hi. a question about using pip. I've been using my OS provided packages with the advantage of them receiving backports of security patches without affecting the installed version. Does pip community supports security patches too for some time on older versions or you have to pull the newest one even if it breaks compatiblity?

[21:54:42] <nanonyme> romanosaurius_re, all packages on PyPI come directly from upstream

[21:54:51] <nanonyme> It's up to upstream to provide backports

[21:55:22] <nanonyme> IOW shorter answer to your question: usually latter

[22:04:11] <romanosaurius_re> nanonyme, thanks. Not meaning that it's a bad thing... just wanted to know the tradeoffs between using pip and the package manager.

[22:07:41] <nanonyme> romanosaurius_re, thing is, with your package manager, your distro maintains package versions based on what's offered by upstream. With PyPI upstream mantains the packages. There's a huge difference

[22:08:28] <dstufft> romanosaurius_re: FWIW I've noticed that "backports of security patches" is very hit or miss

[22:08:41] <dstufft> for major things, yes that'll be backported

[22:08:59] <dstufft> but the less major you get to be, the less likely it'll be backported, with a multipler for how hard it is to do the backport

[22:11:39] <nanonyme> I'd expect the best way to get that done is to join upstream on all the projects you need and push them to do maintenance releases

[22:12:12] <nanonyme> Maintenance releases are probably the most painful part of software engineering, people usually don't do them unless they have to

[22:14:52] <dstufft> (for instance, Debian and ubuntu have some old versions of pip which are completely and grossly insecure, but the patches are more than they've wanted to put effort into patching)

[22:22:34] <romanosaurius_re> dstufft, I was exactly thinking about Debian. I used Debian and got used to the patch management and their advisories in a company with a PCI DSS certification program.

[22:23:11] <dstufft> romanosaurius_re: so in Debian unless you're using testing, the python-pip package doesn't verify TLS at all (or a bunch of other security things we've done)

[22:23:57] <dstufft> so unless you're installing solely from a trusted host on a trusted network and MITM aren't a concern, python-pip is not safe to use on Debian stable unless you upgrade it yourself

[22:24:01] <romanosaurius_re> dstufft, I was more thinking not in pip vs debian's pip but pip packages vs debian's python packages.

[22:24:29] <romanosaurius_re> for example... apt-get install python-django vs pip django

[22:25:02] <dstufft> romanosaurius_re: right, so pip itself is just an example :) A particularly egregious one in my opinion. Mostly it's an example that the backporting of security patches is hit or miss

[22:25:16] <dstufft> I only used ti because it's one I happen to know offhand

[22:27:03] <romanosaurius_re> dstufft, that's a good observation. A sad one anyway as that means that to keep security patches up to date the only really viable option is to risk to lose compatibility by upgrading always to the last version

[22:27:52] <dstufft> romanosaurius_re: my personal strategy is normally to farm out really important things like openssl and whatever to the OS, but keep the python stuff controlled via pip (probably inside of a virtualenv)

[22:28:28] <dstufft> python-django is probably fairly safe one to rely on, since Django itself does patches

[22:28:35] <dstufft> and that makes it easy for debian to pull them in

[22:30:05] <romanosaurius_re> dstufft, that looks good. It's a topic that I see that is very commonly overlooked. Had the same impressions with node's npm and bower.

[22:30:42] <romanosaurius_re> but I'll trust the world to take care of it if it's really that much a real concern

[22:38:10] <romanosaurius_re> well. I'll be going. Thanks everyone for your help and have a nice day/night.