Log file Viewer

[00:00:23] <__machine> instead of defining my deps for utility apps in setup.py install_requires i can define them as git deps in requirements.txt and have snakebasket find them automatically…

[00:40:43] <tomprince> __machine: There are plans for pip to support better dependency resolution, which is part of it.

[00:41:04] <__machine> recursive processing of requirements.txt?

[00:41:05] <tomprince> It wouldn't get around multiple incompatible pinned revisions.

[00:50:45] <tomprince> I don't think it will grow support for that.

[00:51:14] <tomprince> But, perhaps better support for installing packages from vcs when specified as dependencies.

[00:54:04] <__machine> you mean still rely on `install_requires` but have a private index that provides links to git repos … and have pip detect that and install those dependencies as editable git clones so they can be frozen with a commit hash?

[00:55:39] <__machine> this is my main problem… i must use setuptools/install_requires with either dependency_links or a private index in order to have pip recurisively install nested dependencies… but setuptools doesnt know anything about installing editable dependencies… even if it clones a git repo it throws away the repo and keeps just the working copy… so when i pip freeze, i get a string like somelib==1.2.3 … instead of getting a l

[00:56:09] <__machine> so in order to freeze dependencies as links to specific git repo commits i must use requirements.txt … but this is not recursive…

[00:56:36] <__machine> making pip recursively examine requirements.txt could solve my problem

[01:32:40] <__machine> carljm: your comment here https://groups.google.com/d/msg/python-virtualenv/V75HmNu9wqc/s5sNCcVSxIgJ … depdendency links is being removed from pip *and* your suggestion of linking to a changeset specific tarball means that your setup.py is no longer minimally-restrictive — it's the same as ==1.2.3 from a public index…

[03:38:26] <__machine> hmm… the duplicate specification error when a requirement is listed twice in requirements.txt makes it difficult/impossible to split the file apart and include/override some dependencies

[03:51:04] <glyph> tomprince: since versioneer came up, does anyone have any thoughts on https://github.com/warner/python-versioneer/issues/42 ?

[04:12:05] <tomprince> glyph: I wonder about hacks piled upon hacks.

[04:13:04] <tomprince> It seems like the thing you want shouldn't be some pile of code piled on setuptools piled on distutils.

[04:17:43] <glyph> tomprince: right, it should be a regular expression pasted into every single setup.py file that I ever write?

[04:18:13] <dstufft> open + exec

[04:18:15] <dstufft> :}

[04:18:19] <glyph> right, sorry

[04:18:28] <glyph> a regular expression pasted into a file _next to_ every single setup.py ;-)

[04:18:37] <glyph> tomprince: metasetup is perhaps a bad example because of the presence of qualified python identifier names in the metadata JSON

[04:18:55] <glyph> but the idea is that it would be more abstract, decoupling the exact implementation of the hacks from the information being expressed

[04:19:14] <dstufft> open + exec has no regexes!

[04:19:26] <dstufft> but I think it's the copy / paste that is the important part of that

[04:19:26] <glyph> right the thing you exec is a regex

[04:19:27] <dstufft> ;)

[04:19:39] <dstufft> i'm just being smarmy

[04:20:21] <dstufft> you already know my opinions on metasetup though, if it works I thinkit could be nice, but I have the same worried that piling more hacks ontop of setup.py will lead to pain

[04:20:53] <tomprince> glyph: Rather than building the hacks, you should build the new thing.

[04:21:23] <glyph> dstufft: it's like jenga

[04:21:34] <glyph> dstufft: at the end we slide the hacks out from under the bottom

[04:21:47] <glyph> tomprince: "the new thing" being what exactly

[04:21:56] <dstufft> you should work on packaging with me glyph

[04:22:01] <dstufft> want to write a PEP?

[04:22:11] <glyph> tomprince: http://www.joelonsoftware.com/articles/fog0000000069.html

[04:22:25] <glyph> dstufft: ha ha ha I can see _that_ trap from a mile away :-)

[04:22:34] <glyph> dstufft: maybe you can convince me to work on implementing it though

[04:23:52] <tomprince> glyph: Well, if you want to avoid restarting for scratch, you should fork distutils, roll setuptools back into it and proceed from there ...

[04:23:54] <tomprince> (maybe)

[04:24:05] <dstufft> FWIW the new thing isn't going to be complete rewrites like distutils2 tried to be, we'd like to eventually end up o where you can do everything with just new standards, but it's purposely breaking things out to be more modular and rewriting little chunks over time

[04:24:37] <dstufft> like even metadata 2.0 / sdist 2.0 will be generated by setuptools at first

[04:25:42] <dstufft> it's all stuff that will either happen automatically, or be doable by adding an extra setup.py command

[15:51:30] <kinxer> This is the channel in which to ask pip-related questions, right?

[15:55:34] <DanielHolth> ask

[15:56:26] <ghickman> kinxer: yes

[15:56:33] <kinxer> Alright. On Windows, am I to use the default command line to execute Pip installs?

[16:11:17] <kinxer> Forgive my obvious lack of knowledge, but every tutorial seems to assume I would know exactly how to use Pip once it's installed, but I can't figure it out.

[16:11:27] <DanielHolth> C:\pythonsomething\scripts\pip

[16:11:27] <DanielHolth> ?

[16:11:50] <DanielHolth> python -m pip should work too

[16:12:12] <kinxer> I'll try the latter. The former opens a window that closes in less than a second.

[16:12:27] <DanielHolth> yes, you should run cmd first

[16:12:30] <DanielHolth> some people like powershell

[16:13:22] <kinxer> This seems to work. Many Thanks.