[00:00:22] <dstufft> njs: I almost have my PEP thing ready to show people! Probably by tomorrow I'll have it fully ready. There will be some stuff that I'm not 100% sure on what the "shape" of the data should be (as in, what data is reasonable to assert must exist at which point) but if it's a reasonable direction thta's shit we can hash out later... or it can be a terrible idea and we reject it :D /cc lifeless
[00:02:32] <lifeless> dstufft: don't keep us in suspense
[00:03:03] <lifeless> njs: dstufft: re flit and py2/py3 no, we're not doing that shit
[00:03:31] <lifeless> if flit is py3 only, and it wants to be used to install py2 things
[00:03:42] <lifeless> then flit can't be installed by pip and needs to be treated like autoconf
[00:04:29] <lifeless> -> it gets the right python from the environment ( I think PYTHON is already a variable for exactly this case )
[00:04:57] <njs> I strongly suspect the solution in real life will be that Thomas sucks it up and ports to py2 \intersect py3
[00:04:59] <lifeless> I'm hunting food now, I'll hop on github and answer with this after that
[00:05:14] <lifeless> separately we need to really pin down the user/root/prefix stuff
[00:05:19] <dstufft> lifeless: honestly, the only reason it's not public right now is just because it has strawman-esque stuff in it that I don't want to defend and I plan to remove and I don't want to poison the well either :]
[00:06:03] <dstufft> njs: alternatively the solution is he just says flit is only for py3 things.
[00:06:14] <dstufft> which isn't wrong, but makes it far less useful
[00:07:01] <njs> lifeless: for the user/root/prefix stuff -- I think the answer is just (a) for wheels that's pip's job, (b) for editable installs, all you need in the interface is prefix (and pip can map everything else into that)
[00:08:04] <dstufft> I kinda feel like punting on editable installs OR saying the build tool's job is to do an inplace build and let it be someone else's job to do the egg-link magic
[00:08:24] <dstufft> but editable installs are kind of terrible with all sorts of rando edge cases that don't work
[00:15:28] <lifeless> dstufft: so I want us to do that right, as a separate iteration
[00:16:06] <lifeless> rather than stalling this for 3-4 months while we figure out all those interactions
[00:19:46] <njs> my favorite part about editable installs is that they make proper dependency resolution impossible because you just never know what version you actually have installed. Like... this is just a fundamental structural problem that is not going to be fixed by tweaking the design around :-/.
[00:21:00] <njs> ...I probably shouldn't have even typed that though b/c I agree w/ lifeless that for this round of PEPs we absolutely need to find some way forward that *doesn't* involve addressing the fundamental problems
[00:38:38] <dstufft> I don't think that either of my two things address any fundamental problems :D
[00:38:51] <dstufft> I think it's jsut shuffling deck chairs or refusing to do it
[01:05:48] <StevenK> dstufft: https://github.com/pypa/pip/pull/3307 is also ready, building on the new packaging stuff -- this is also a branch you started on, I just cleaned it up and made sure the tests passed.
[01:13:34] <StevenK> lifeless: https://bitbucket.org/pypa/setuptools/pull-requests/173/switch-to-packaging-markers-requirements/diff is also a thing, so while I disappear to buy lunch, what should I dive into next?
[01:38:24] <lifeless> dstufft: can you merge https://github.com/pypa/interoperability-peps/pull/61/files ?
[01:38:43] <lifeless> StevenK: anything appealing on trello?
[01:48:54] <njs> lifeless: at some point I'd be interesting in checking in on the status of the resolver stuff, and if there's any way to help nudge it forward
[02:01:51] <lifeless> njs: I think that we need --prefix and --root still perhaps
[02:01:58] <lifeless> njs: remember that develop mode writes a .pth file
[02:02:45] <lifeless> njs: so the question is, is there a situation which pip can't influence the place the .pth file is written appropriately without --root (and perhaps we need --user too?)
[02:03:28] <StevenK> lifeless: I was tempted to rewrite pkg_resources.Requirement.__init__ so it will take a packaging.requirements.Requirement instance, and populate from only that
[02:04:38] <lifeless> has __init__ needed to change so far?
[02:05:26] <StevenK> lifeless: No, but it also loses information from packaging.requirements.Requirement, most notably marker and url
[02:05:26] <njs> lifeless: at least according to the distutils docs, --user is equivalent to --prefix=site.USER_BASE
[02:05:58] <lifeless> StevenK: I thought you poked them in ?
[02:06:14] <lifeless> njs: well remember that setuptools differs from distutils sometimes
[02:06:24] <StevenK> lifeless: I poked them in where they were needed, not in pkg_resources.Requirement itself
[02:06:39] <lifeless> StevenK: I could see either working
[02:06:52] <lifeless> StevenK: perhaps in the review put that suggestion up
[02:07:00] <lifeless> StevenK: and see what jaracao thinks
[02:07:08] <lifeless> njs: I'm not sure it differs here
[02:07:15] <lifeless> njs: but I know e.g. data_files differs
[02:08:39] <njs> lifeless: one thing to note is that currently --root is totally ignored for editable installs, and I guess no-one has noticed
[02:10:25] <lifeless> --isolated Run pip in an isolated mode, ignoring environment
[02:10:28] <lifeless> variables and user configuration.
[02:11:12] <njs> oh right, that adds the excellent "--no-user-cfg" option to the call to setup.py, whatever that is
[02:11:54] <lifeless> I'm inclined to think that that should be tunnelled through
[02:12:37] <lifeless> how is --root expressed in prefix terms?
[02:13:34] <njs> my impression was that the "effective prefix" is $ROOT/$PREFIX, and the reason that there are two different switches is that in the UI it is nice to be able to set one while accepting the default for the other
[02:13:50] <njs> but I am only about 30% confident in that :-)
[02:16:15] <njs> if --root is supposed to be the equivalent of DESTDIR, then I guess the other tricky thing would be that you want to write all file-to-file references in the code *as if* the code is being installed to /$PREFIX, even though it's really being installed to $ROOT/$PREFIX, because the assumption is that sometime between when you install and when it actually gets used it will be moved to that location
[02:16:24] <njs> (e.g. because it gets tarred up into a .deb, and then the .deb will be installed)
[02:17:00] <njs> I don't know if this is any of (meaningful, supported, relevant) for editable installs, and suspect it isn't
[02:17:35] <lifeless> I am thoroughly confused by prefix vs root
[02:21:05] <njs> yeah that matches my understanding
[02:21:19] <njs> the other important question is whether it has any effect on the actual files that it puts there
[02:22:53] <lifeless> if it did it would be batshit
[02:22:57] <njs> AFAICT the only filename that gets written down in the install directory by 'setup.py develop' is the absolute path to the source tree
[02:23:13] <njs> so that shouldn't be affected by --root/--prefix, that makes no sense
[02:24:32] <njs> it isn't batshit in the general case -- e.g. if --root is supposed to act like DESTDIR, then in your example the record of installed files should contain paths like "/home/robertc/.virtualenvs/..." instead of "$(pwd)/t/root/home/robertc/..."
[02:25:59] <njs> also, it turns out that the only thing that --no-user-cfg does is tell distutils to skip reading ~/.pydistutils.cfg. It doesn't like trigger -S or anything complicated like that.
[02:26:15] <njs> it's also not at all clear what this means for other build systems :-/
[02:27:25] <njs> I guess we could say that --isolated should be like --global-option=--no-user-cfg, and that at least reduces to the existing problem of what to do about --global-option :-)
[03:05:06] <StevenK> lifeless: So I think the packaging card in Trello is done, the PEP has landed, and the code is in a packaging release
[21:02:13] <lifeless> dstufft: did you mail that send?
[21:02:31] <lifeless> StevenK: so trello cards are done?
[22:07:41] <xafer> Any sphinx veteran available ? pip's docs build is failing with `pip/docs/development.rst:18: WARNING: Could not lex literal_block as "python3". Highlighting skipped.`
[22:16:15] <xafer> Ok, for some reasons, pip docs build installs Sphinx==1.4a1 :-/