Log file Viewer

[05:48:42] <_habnabit> so i just reread the post about setup.py vs. requirements.txt and i still don't understand in what case you'd use requirements.txt

[05:48:58] <_habnabit> it doesn't get included with wheels, and pip doesn't use it if you're installing from an sdist

[05:49:17] <dstufft> _habnabit: environment re-creation

[05:49:26] <dstufft> _habnabit: think chef cookbook, not .deb

[05:50:50] <_habnabit> dstufft, i was thinking about it, but i don't know if i know enough about chef to understand that analogy

[05:53:36] <dstufft> _habnabit: another example: you might deploy from a requirements.txt (and likely pin exact versions), but you (probably) wouldn't deploy straight from a setup.py

[05:54:48] <_habnabit> dstufft, how, exactly, would you deploy from a requirements.txt? my deployment situation is a bit flexible right now but i've been trying to figure out the best way to put a .pex in a .deb

[05:56:02] <dstufft> _habnabit: taking that example, you might build a pex from a requirements.txt file pinned to exact versions (so you can easily reproduce the pex)

[05:57:25] <_habnabit> dstufft, i think my original plan was to build a pex from pulling packages off pypi instead of relying on having a git checkout on the pex builder box

[05:57:38] <_habnabit> dstufft, i can't remember why

[05:58:03] <dstufft> _habnabit: that's doable, the problem with that is that two seperate invocations of pex may give you different versions of things

[05:58:19] <_habnabit> dstufft, well, unless my install_requires of the root package pins versions

[05:58:26] <_habnabit> dstufft, but that's what the blog post says not to do

[05:58:48] <dstufft> sure, generally you don't want to do that in an install_requires, because if multiple things do that it becomes basically impossible to satisify all the version constraints

[05:59:18] <_habnabit> dstufft, my plan was to only pin versions in the install_requires of the 'root packages' which would be pulled in when building a pex

[05:59:44] <dstufft> but if you do that, the beneifts of requirements.txt isn't very much, because you're essentially using your install_requires as your requirements.txt

[06:02:48] <_habnabit> dstufft, so, i suppose my question is: how bad would it be to make the install_requires of an /application/ (i.e. not a library, and only one application would be put in a single .pex) have pinned versions?

[06:03:29] <dstufft> depends on if you ever want to install that application alongside another thing

[06:03:34] <dstufft> outside a of pex

[06:04:44] <_habnabit> dstufft, i can't think of any situation where that would make sense

[06:06:43] <dstufft> _habnabit: then the downsides are minimal

[06:06:53] <_habnabit> dstufft, what downsides would there still be?

[06:07:43] <dstufft> _habnabit: basically just that changing your dependencies versions requires a version bump on your app

[06:07:57] <_habnabit> dstufft, imo that's a feature, not a bug

[06:08:38] <_habnabit> dstufft, i mean, in the end it's going to be a deb anyway, and that will require a version bump for every deployment

[06:09:09] <dstufft> yea

[06:45:34] <tomprince> _habnabit: Just pinning the root dependencies won't give you a repeatable deployment, though.

[06:47:32] <_habnabit> tomprince, i know; i pin transitive dependencies too

[06:50:24] <tomprince> So one benefit, is that it seperates the list of all pinned transitive dependencies from the root dependencies.

[06:50:46] <_habnabit> tomprince, true

[06:51:22] <tomprince> If you use console entry points, pinning in requirements.txt vs. setup.py means that it is easier to switch around dependencies for testing.

[08:40:57] <ronny> dstufft: ping? whats the state of the virtualenv rewrite?