Time to tickle the sleeping dragon. What follows is a summary of the state as I understand it:
There haven’t been any posts disagreeing with @dstufft’s proposal a few days ago. There is some discussion over whether the specification should say projects MUST support being built purely from sdist (avoiding build cycles), or if this is merely a SHOULD. @njs points out that we can’t realistically enforce it, so the practical difference is limited.
I see on the discussion of setuptools PR 1674 that @pganssle feels somewhat disillusioned with this thread. Perhaps it’s never a true packaging discussion until it’s over 100 messages long and we’re all fed up with it, but Paul, I hope you’ll rejoin the conversation. We build stronger tools when we consider more perspectives, even if we can’t satisfy everyone.
As I understand Paul’s position, he is concerned that an easy way to put the source directory on
sys.path will be cargo-culted to let
setup.py import the source of the package, a headache which setuptools is trying to get away from. His preferred options are to force installing wheels for build dependencies, letting people who insist on ‘from source’ builds figure out bootstrapping themselves, or to have a special sentinel value of
build-backend= which tells frontends to use a specially named file in the source directory as a build backend.
Paul, please correct me if I’ve misrepresented your position.
I think we have basically agreed that we want to make some provision for bootstrapping within PEP 517, so we’re taking the ‘force build-deps as wheels’ option is off the table (discussion starting here convinced me). That leaves us with two basic options:
- A way to add one or more directories to
sys.pathbefore finding the backend (Donald’s proposal and variants thereof)
- A special build-backend name which tells the frontend to use a well-known filename in the source tree such as
_build_backend.py(Paul’s proposal from some time ago). Please delay any bikeshedding about the specific names to use.
I’d ask all of us who have a preference to seriously consider the other option. Can we live with it?
Paul: I know I’m rehashing points already covered, but people using
setup.py will have at least two other ways to get the source directory on
sys.path: adding it in
setup.py itself, and explicitly declaring the setuptools legacy backend. People who find their setup is broken and don’t want to think about fixing the issue are going to find ways to work around it. Is it so bad if there’s a third way?
(I tried to come up with some compromises that would let us add directories to
sys.path only for finding the backend, but I’ve since been convinced that these are not worth the extra complexity)
People who prefer option 1 (including me): does option 2 have serious problems, or just cosmetic ones? I think pretty much everyone in the discussion besides Paul is in this camp, so if we can’t reach agreement we could presumably overrule his concerns, but he has put a lot of thought and effort into trying to get away from the problematic import-yourself-in-setup.py pattern, and he clearly believes that this option undermines that. If we decide to specify option 2, I know I’d go away and implement it for Flit happily enough.
Finally, I hope we can wrap this discussion up without returning to the hailstorm of messages it was for a while. I know I’m as bad as anyone in this, but I’m going to make an effort to read, think, and reply slowly. I hope you’ll join me. Exhausting people so they drop out of the conversation is not a healthy way to reach consensus.