As noted on the PR, bikeshedding season on the name is now open - @takluyver preferred something specifically relating to the backend, like backend-path, and I’m inclined to agree with him. But if we end up going for python-path[s] then I agree with your reasoning that path is better.
If there’s a significant debate over names for the key, what I’ll probably do is set up a vote here, and go with a simple majority preference. I don’t want to have naming trigger a whole other round of debates on semantics.
Regarding the check, we can debate actually adding it in the relevant frontend trackers (pip and pep517). Unless you’re objecting to stating that we don’t support using this feature when using a standard (not in-tree) backend, I think “frontends MAY” is weak enough to satisfy your preference for not bothering with an actual check.
I basically agree with everything @dstufft said. I’m nervous about unexpected consequences, and I dislike adding extra hair to packaging without adequate justification. (Packaging has way too much hair.) But at this point I’ve made my case, and it sounds like even the proponents are only arguing “this adds complexity and doesn’t have much justification, but we like it better anyway”, so, well, it’s just taste on both sides, so not much more to argue about. And I’m tired of arguing anyway :-).
Regarding the name: I don’t have a strong feeling either way. Since this is intended to be a rare experts-only feature with a fairly narrow use-case, my styleguide suggests giving it a somewhat longer and more explicit name that mentions that use case, like backend-bootstrap-path or in-tree-backend-path. But I’m just throwing that out there.
I think the discussion has now pretty much petered out, and there haven’t been any more review comments on the PR.
So over the next few days (RL is a bit hectic right now!) I’ll update the PR to address the review comments, and pick a name (probably backend-path) for the option. Then, unless there are new comments/reviews in the meantime, I’ll merge it and count it as done. And we can move on to implementing it
Thanks everyone, for a fruitful and constructive discussion. In particular, thanks to people for being willing to compromise and work for a consensus. What we ended up with wasn’t exactly where this discussion started, but I think the solution is better for the time we spent on it.
I certainly intend for Flit to be self-building via this mechanism. I’m actually considering splitting the backend part out as a separate package from the command line interface.
That might be nice. I was thinking that an absolutely minimal backend that just built a wheel from a set of pure Python source files would be a great low-level building block. Maybe the backend part of flit could be that? (Although I presume it would retain flit’s mechanism of getting the files to include from git, so my idea is somewhat different, and even more low level).
Flit doesn’t use git to decide what goes in the wheel, only for building an sdist. For building wheels, I meant it to be pretty close to your ‘absolute minimal’ backend, but then sdists complicated the picture.
This might be an opportunity to revisit the choice to use a VCS to select files. I think it makes sense in a tool used by the package author, but not so much in a build backend. I was already thinking about writing a MANIFEST file into an sdist so Flit could use an unpacked sdist as the source for another sdist.
I’d welcome other ideas about how to select files for the sdist, although if anyone’s interested we should probably split that discussion out of this thread.
