PEP 517 Backend bootstrapping

(Paul Moore) #241

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.

(Pradyun Gedam) #242

Uhh… I made inline comments on the PR but missed @pf_moore’s last comment.

I think backend-path looks good.

(Nathaniel J. Smith) #243

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.

(Paul Moore) #244

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 :slight_smile:

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.

(Paul Moore) #245

Change to PEP 517 has been merged, and will be live at once the auto-build runs.

(Bernat Gabor) #246

Thanks for managing this! Any self building backends available/planned as of now?

(Thomas Kluyver) #247

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.

(Paul Moore) #248

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).

(Bernat Gabor) #249

A MVP build frontend might be nice, so backend implementors can test with it their part :laughing:

(Thomas Kluyver) #250

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.

(Bernat Gabor) #251

I would say take all with a ignore list (and we can have a sane ignore list defined as the VCS, editors, and some user defined part (CI files).

(Paul Moore) #252

I’ve just created implementing the backend-path part of this change. Reviews would be welcome :slight_smile:

Still to do:

  • Update pip to use this
  • Add requirement cycle checking to pip