Log file Viewer
#pypa-dev logs for Wednesday the 2nd of December, 2015
[18:31:48] <ErikRose> I'm updating peep's docs to say it'll be deprecated and wanted something to point at.
[18:57:01] <dstufft> lifeless: I haven't forgotten, jjust been all over the place :( haven't had a lot of time in long chunks this week really. The title company "misplaced" the money I sent them, so I was calling all over trying to straighten it out
[18:59:13] <dstufft> lifeless: I don't mind it, but I'm guessing I'm not going to get a whole lot of continous dedicated time until after next week when the move is finally done :/
[19:39:16] <lifeless> dstufft: there's no impl yet, and you were clear you wanted one for things you're pronouncing on
[19:51:34] <dstufft> lifeless: I have a bit of a headache and I feel like it was discussed already, but I don't remember why we have a metadata command instead of just building wheels
[20:04:05] <dstufft> lifeless: overall it looks OK to me, I'm still not a fan of expecting users to type out JSON, and I think a INI or TOML or YAML (if we can get a decent pure python implementation) is better, but that's a fairly minor thing. The two big questions in my read through are A) Develop installs blur the line between build tool and install tool, do we really want to add them here or would it be better to instead add a "Build inplace" command and
[20:04:05] <dstufft> then have pip drop a egg-link or whatever that it needs? I know long term we'd want a PEP for that, but an inplace build + a shim in pip seems better than bluring the lines here (but that's off the cuff) and B) There's another question here about whether we should mandate the capability to generate sdists or not, which includes the discussion of if ``pip install .`` should generate a sdist first or if it should just build a wheel straight
[20:04:43] <dstufft> those are the only things that I really see that stand out to me, and I'm not _unhappy_ with the answers as they are in the PEP or mandating they be something else, just the thoughts that pop into my head
[20:07:54] <dstufft> lifeless: overall though, it looks good, and I wouldn't be upset if it landed in it's current state
[20:08:11] <lifeless> a) develop blues the line, but its a separate problem to solve. I don't like boiling the ocean.
[20:08:26] <lifeless> This will give us the framework to solve it with clearcut compat lines; which is a good thing.
[20:09:05] <lifeless> develop is nontrivial - we've already had inconclusive discussions about 'pip install -e .' semantics in the context of deprecating the use of 'setup.py install / develop ...'on-list
[20:09:29] <lifeless> so, this just codifies what pip already does. I think thats fine - its better than it being an undocumented interface.
[20:10:05] <lifeless> b) If we want to require packages can make sdists, the right place IMO is to have pypi refuse wheels-without-sdists
[20:11:03] <dstufft> yea, I just worry about backing into a corner wrt install side features (since it'd mean we couldn't add something like --prefix to -e without a new PEP), but it's just a worry and I always have worries about things :) I don't have a particularly great idea to solve that without boiling the ocean, other than ones with different tradeoffs
[20:18:06] <dstufft> Requiring sdists on PyPI would just mean that there must be some way to generate a sdist (even by hand) but it doesn't mean that pip is able to take advantage of that. Right now if you do ``pip install .`` we cp -r the entirety of . to a temporary directory and then run ``setup.py install`` or ``setup.py bdist_wheel`` from there. We do that to isolate ``.`` from any side effects of the build process, however that can take a long time if
[20:18:06] <dstufft> people have a lot of extraneous crap in their ``.``. See for example https://github.com/pypa/pip/issues/2880, where his checkout of cryptography had ~1GB of extra crap inside of a .tox which made the copy take a lot longer. There was a PR awhile back that attempted to prevent this by filtering some common direcotries (like .tox, and .git, and such) but those break things like pbr and setuptools_scm that want to treat a git checkout
[20:18:59] <dstufft> So our only real options are to either live with a really slow ``pip install .`` sometimes for unobvious reasons (which I think is crummy), mandate the ability to create a sdist, or remove the copy and let ``pip install .`` crap all over the ``.`` directory
[20:20:21] <dstufft> I greatly prefer mandating the ability to create an sdist, because then it also reduces the permuations of ways a thing can be installed, I know the SciPy folks prefer us to remove the copy because they want to crap all over the ``.`` directory to cache builds.
[20:20:51] <dstufft> However, I don't tihnk it's absolutely required that this PEP addresses it, because we could just keep the copy and then address a mandatory sdist at a later point
[20:25:04] <dstufft> there's no way right now to query the tool about what version of build system it supports. I guess that's somewhat implied in the pypa.json schema value... but that only really tells you how to read that particular file and I think it'll cause problems if we make a new version of this that requires sdists (or any other change) but that doesn't require a change to pypa.json, either users will have to bump their pypa.json schema file manually
[20:25:04] <dstufft> (and this might happen implicitly if their bootstrap_requires are not version capped) or if they don't you'll get a sort of split brain thing where the pypa.json thinks it's 1 thing and the tool is actually implementing another thing
[20:25:36] <dstufft> might be sane to add something to query the build tool itself for what version of the build API it's working against
[20:29:38] <lifeless> but I've failed to convince you of that, primarily I think because you wear the support calls when folk publish bad crap
[20:30:19] <lifeless> will people make mistakes? yes, but it will be very very obvious and break straight away
[20:30:38] <lifeless> I *removed* the whole query indirection layer because you felt it was too heavyweight
[20:33:04] <dstufft> this isn't something like the whole query indrection thing, this is just something like $BASECOMMAND api_version or something. I feel like expecting end users to bump schema just because their build tool happened to create a new release is the wrong thing to do
[20:38:00] <dstufft> I mean, let's pretend this PEP is accepted and everyone switches to it, then in a year we add a new PEP that adds a new flag to the ``wheel`` command, if the build tool can inform pip of what version it's implementing, then pip can ask it that, and people will just silently get whatever new feature that enabled... otherwise that new feature is going to require _every_ package author to go through and update their schema in the .json....