On 3 June 2017 at 09:59, Paul Moore <p.f.mo...@gmail.com> wrote: > On 3 June 2017 at 03:14, Nathaniel Smith <n...@pobox.com> wrote: >> So far my belief is that packages with expensive build processes are >> going to ignore you and implement, ship, document, and recommend the >> direct source-tree->wheel path for developer builds. You can force the >> make-a-wheel-from-a-directory-without-copying-and-then-install-it >> command have a name that doesn't start with "pip", but it's still >> going to exist and be used. Why wouldn't it? It's trivial to implement >> and it works, and I haven't heard any alternative proposals that have >> either of those properties. [1] > > I may be misunderstanding you, but it's deeply concerning if you're > saying "as a potential backend developer, I'm sitting here listening > to the discussion about PEP 517 and I've decided not to raise my > concerns but simply to let it be implemented and then ignore it". > OTOH, I'm not sure how you plan on ignoring it - are you suggesting > that projects like numpy won't support "pip install numpy" except for > wheel installs[1]? > >> One thing that's not clear to me: a crucial use case for sdists is (1) >> download, (2) unpack, (3) patch the source, possibly adding new files, >> (4) build and install. (After all, the whole reason we insist on >> distributing sdists is that open source software should be modifiable >> by the recipient.) Does flit currently support this, given the >> reliance on VCS metadata? > > That's a reasonable concern, and a reservation I have about flit's > sdist support, but as a comment about flit, it probably belongs more > on the flit tracker than here. > > As a point for PEP 517, I think it's valid though. I'd suggest that > the PEP add a few more lines on what constitutes a "source tree", by > offering some examples. It seems to me that the two key examples of a > "source tree" that the PEP must support are > > 1. A VCS checkout of a project under development. > 2. An unpacked sdist that the user has made edits to before building. > > (The second of these being the one we're talking about here). > > Paul > > [1] By "won't support" consider that in a PEP 517 world, pip issues > stating "pip install <numpy source checkout> takes too long" or > similar will be passed to the backend developer with the suggestion > that they implement the build_sdist or copy_files hook. Saying numpy > won't support PEP 517 means that such requests will be denied.
Apologies, gmail's web interface split the conversation thread so I wrote this before reading through to the end, so some of what I say is out of date given subsequent emails. Bad gmail, sorry :-) Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
