• Restructure builder's API, reducing it to

  • a prepare(src: Path, dst: Path) -> Builder context manager
    which sets up an isolated environment and installs the build system's dependencies
  • a Builder abstract class exposing build, metadata, and zipapp methods

  Builder is made abstract, so instances can only be obtained within the managed context, ensuring the build environment was not cleaned up between calls. (Unless one uses RTTI to get the concrete class from a prepared object, or does not use prepare as a context manager...)

• Add tests for builder ensuring there are no dependencies left on

  • method-call order, nor
  • global state, including:
    • current working directory
    • filesystem state (outside of the IsolatedEnv itself, which is a fresh directory beneath /tmp and source dir)
      in particular the contents of the destination directory should not matter

• Fix suboptimal use of the builder API, due to API limitations in the rest of bork

  • api.build and api.build_zipapp do not reuse the same Builder, causing isolated environment and wheel to be built twice ;
  • api.release does not have access to the Builder's returned artefact Paths and PackageMetadata, instead performing filesystem-augury
  • pypi.Uploader.upload isn't passed the metadata, and would have to rebuild it again... with no guarantee that the source wasn't modified between bork build and bork release 👿
    That issue already existed, so I won't consider it a blocker for this PR.

  I think I can safely say this will be addressed in follow-up PRs, given that we'll likely end up rewriting Bork's entire API surface, both internal and public.

PS: I just realised I could just squash all those commits together, given that I did a few minor refactors... then rewrote the entire hecking file >_>'