Log file Viewer

[01:02:52] <Ivo> xafer247_: are you xafer?

[01:10:03] <Ivo> added a comment

[01:32:59] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:32:59] <pmxbot> Add __ne__ method to Requirement class

[01:32:59] <pmxbot> Update changelog

[01:32:59] <pmxbot> Added tag 14.1 for changeset 9751a1671a12

[01:32:59] <pmxbot> Bumped to 14.2 in preparation for next release.

[01:41:42] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:41:42] <pmxbot> Merge

[02:42:55] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[02:42:55] <pmxbot> Remove regression test for Distribute issue #318. The continuing relevance of this test is questionnaible, given that user installs of setuptools no longer imply user installs of other packages. Ref #360.

[02:42:55] <pmxbot> Bypass the checking of site-packages when asserting not user install in site-packages. Fixes #360.

[02:42:55] <pmxbot> Update changelog

[02:45:34] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[02:45:34] <pmxbot> Bumped to 14.1.1 in preparation for next release.

[02:45:34] <pmxbot> Added tag 14.1.1 for changeset 07fcc3226782

[02:45:34] <pmxbot> Bumped to 14.1.2 in preparation for next release.

[12:19:23] <pmxbot> jaraco pushed 5 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[12:19:23] <pmxbot> ensure py_version and platform are str in hashcmp

[12:19:23] <pmxbot> Update changelog

[12:19:23] <pmxbot> Bumped to 14.2 in preparation for next release.

[12:19:23] <pmxbot> Added tag 14.2 for changeset d714fb731de7

[12:19:23] <pmxbot> Bumped to 14.3 in preparation for next release.

[13:47:56] <pmxbot> jaraco pushed 5 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:47:56] <pmxbot> Default to 755 permissions since checks later on test for non-group-writability

[13:47:56] <pmxbot> Remove unused parameter.

[13:47:56] <pmxbot> Update changelog. Fixes #254.

[13:47:56] <pmxbot> Added tag 14.3 for changeset e3c635a7d463

[13:47:56] <pmxbot> Bumped to 14.4 in preparation for next release.

[23:34:27] <lifeless> dstufft: ok so

[23:34:39] <lifeless> dstufft: is there a PEP or something around setup_requires replacemnet?

[23:35:24] <lifeless> dstufft: its just that 'do something thats in dstuffts head' isn't very actionable :)

[23:36:26] <dstufft> lifeless: there's no PEP or anything no, the only thing I got is some experiments at https://github.com/pypa/pip/compare/develop...dstufft:eldritch-horror

[23:36:45] <dstufft> the tl;dr is monkeypatch the setup.py invocation so we can control what happens with setup_requires

[23:37:09] <lifeless> dstufft: have you considered not doing that

[23:37:24] <lifeless> dstufft: and instead doing a clean replacement that folk can migrate to? e.g. a setup.cfg entry?

[23:37:36] <lifeless> dstufft: + entry in the wheel metadata of course

[23:37:56] <dstufft> the clean replacement is part of PEP 426

[23:39:52] <lifeless> dstufft: thats still stalled no? Is it possible to do some strict subset of 426 - because setup_requires is the last major OMGWTF pain point ...

[23:42:24] <lifeless> dstufft: I might raise this on the list actually

[23:42:38] <dstufft> lifeless: stalled in the sense nobody is working on it right now, I'm the only person with dedicated time and now that PEP 440 is out I'm focusing on Warehouse for awhile before jumping back to client side

[23:43:18] <dstufft> that doesn't mean it needs to wait for me, but just that I'm the only one whose currently got enough time that I'm willing to spend on packaging to really flesh out all the potentional issues and push it forward

[23:43:44] <lifeless> dstufft: so, I just re-read 426 and I don't see how it solves setup_requires... it solves it for *distributions*, but not for local dev, but local dev is where I see and feel the pain

[23:44:03] <lifeless> dstufft: I'll start a thread, and you can tell me there where I'm being nuts :)

[23:44:19] <dstufft> oh, right we're primarily focusing on install side and working our way backwards

[23:45:25] <dstufft> where we == the people who are currently putting any effort into it, not we == that's th eonly area we're willing to consider ATM

[23:45:54] <lifeless> sure, totally get it

[23:47:15] <dstufft> I know that Daniel Holth expressed some interest in a stop gap for setup_requires

[23:48:23] <dstufft> I'm not convinced it's going to be a generally useful construct since it's only going to work on the absolute latest versions of tooling you're still going to need to support the legacy methods of doing things unless you're able to cut out every version of linux that's already out there, and OSX, etc.

[23:49:09] <dstufft> that's my initial gut feeling on it

[23:52:23] <dstufft> We have a lot shorter timeline for updates than Python itself, but we're still fairly long and new features can't generally be relied on immediately (and we need to support them for damn near forever) which makes me nervous about adding shims that aren't desired to be mostly transaprent to users

[23:53:00] <dstufft> which is why something based on dynamically modifying the setup.py was attractive to me, because that would kick in automatically and just wrest control of setup_requires, even though it's fairly hackish itself

[23:55:46] <lifeless> I think its acceptable to say that folk wanting out of the pain upgrade their dev platform

[23:56:06] <dstufft> it's not just dev though, it's deployment too

[23:56:10] <lifeless> we can then ignore setup_requires when the new thing is present

[23:56:35] <lifeless> and for transition folk can put the values in setup_requires and some explicit read-without-interpret file

[23:56:36] <dstufft> if you want setup_requires in dev you need it when some random person does ``pip install thing-you-jsut-uploaded``

[23:56:53] <lifeless> yep

[23:57:09] <dstufft> (What's the dev specific pain btw?)

[23:57:43] <lifeless> When I change deps I have to go to all my dev venvs and manually tweak

[23:58:16] <lifeless> or face the awful when setup_requires kicks in

[23:58:27] <lifeless> this is for the projects that have a single version metadata that setup.py imports

[23:58:34] <lifeless> e.g. unittest2

[23:58:44] <lifeless> or testtools

[23:59:13] <lifeless> I'd like to pull the pbr solution to this out into something e.g. setuptools

[23:59:58] <lifeless> [that is to have a thing you import to get version_info __version__ etc, which reads metadata files