Log file Viewer

[02:08:44] <lifeless> ERROR: pep8: could not install deps [flake8==2.3.0]; v = InvocationError('/home/travis/build/pypa/pip/.tox/pep8/bin/python -m pip install --pre flake8==2.3.0 (see /home/travis/build/pypa/pip/.tox/pep8/log/pep8-1.log)', 1)

[02:12:46] <lifeless> dstufft: ^

[04:00:55] <qwcode> lifeless, were you concerned about solving setup-requires conflicts with a UI like pip offers for overriding conflicts for install_requires?

[04:01:43] <lifeless> I'm noting that that is a consequence of the decision to have setup-requires isntalled in a separate namespace

[04:02:01] <qwcode> lifeless, noting what

[04:02:14] <lifeless> that we have no way to work with such conflicts

[04:02:18] <qwcode> right

[04:02:28] <qwcode> dstufft, ^

[04:02:46] <qwcode> dstufft, this is what I was referring to

[04:04:12] <qwcode> lifeless, I'll admit I never even conceived of worrying about that for setup-requires, but you've seen this in the wild where you want this?

[04:05:06] <lifeless> no more than the side effects of installing setup-requires into the target environment that has folk all worried

[04:05:20] <lifeless> we can't claim its a problem for the target environment and not for the build environment :)

[04:05:31] <qwcode> lifeless, understood

[04:05:59] <lifeless> logically if we're not worried about it for setup's, we should be ok installing the setup dependencies into the target

[10:39:33] <dstufft> lifeless: I don't understand how we don't have a problem with conflicts with out setuptools installs things but we would with how pip installs things for setup_requires

[16:15:01] <cwarner> hi, are there any good reasons --process-dependency-links is still with us?

[16:15:21] <dstufft> cwarner: why wouldn't it be?

[16:15:59] <cwarner> well, if you are using --process-dependency-links then we assume you've populated the dependency_links list

[16:16:36] <cwarner> I mean i'm trying to understand why I would need an explicit arg for that purpose

[16:17:14] <cwarner> it looks like it was to be removed at some point or something

[16:17:24] <dstufft> because installing random things from PyPI shouldn't be able to silently force you to pull dependencies from a domain other than what you've configured

[16:17:37] <dstufft> it's going to be removed eventually, but not until we have a better replacement for the private package case

[16:17:56] <dstufft> but the whole dependency links feature is going to be removed with it

[16:18:22] <cwarner> so whats in the works then?

[16:19:18] <dstufft> "direct depedencies", you'll be able to do something like install_requires=["foobar @ https://github.com/...."], and PyPI will reject uploads that contain direct dependencies

[16:21:10] <cwarner> mmmmmmmmmmm ok...

[16:28:01] <tomprince> dstufft: How will you enforce that (given that it can be dynamic)?

[16:28:21] <dstufft> tomprince: it'll be tied into the new PEP 426 metadata which is static

[16:30:45] <tomprince> It seems (given that pip still has to support old metadata) that it should be possible to get around that.

[16:31:28] <tomprince> I guess ... packages can do anything they want when you install them anyway.

[16:35:36] <cwarner> pretty much

[16:36:30] <cwarner> I get the angle though and would rather a failure that invokes me to actually look than just doing it if that's the case

[16:40:01] <dstufft> Generally yea given we're executing setup.py in the "legacy" format you can do pretty much whatever you want, though even with the legacy format we're trying to provide a path that leads people to behave in the way we think is correct and the way that'l give them the least amount of pain when moving to the new stuff

[16:40:54] <dstufft> Sometimes we get a little over zealous (like trying to remove --process-dependency-links and dependency_lniks before we had a replacement in for it)

[16:42:53] <cwarner> I don't have the data to refute and I rather a safe than sorry approach with this sort of thing.. I can wait and I have a work around for my build systems so I'm ok