One of the major pain points for any build backend is adopting dependencies (https://github.com/pypa/packaging-problems/issues/342). As soon as any backend adds a dependency that's not built on flit-core, it runs into a cyclic dependency on itself and breaks source-only builds.
coherent.build hits this cycle on the first loop - coherent.build requires coherent.build to build.
Setuptools "solves" this problem by vendoring all of its dependencies, though it wishes not to do so.
Hatchling "solves" this problem incidentally by only having dependencies on projects that use flit-core or setuptools. If any of its dependencies were to adopt hatchling or if any of their dependencies were to adopt hatchling, it would have a circular dependency.
coherent.build doesn't solve this problem (source-only builds are broken).
flit-core solves the problem by implementing the whole of its functionality on the stdlib (a suitable approach, but doesn't generalize).
But it occurred to me - what if coherent.build, instead of producing sdists that depend on coherent.build, built its sdists to rely on flit-core. That is, all of the complicated work that relies on dependencies is in the "discovery" of metadata, and all of the metadata is materialized in the sdist. coherent.build could produce sdists that use a different build backend that merely copies the files and metadata into a wheel.
This approach would mean that system integrators and build frontends could install coherent projects from source with nothing but flit-core.
PEP 621 provides a way to provide the metadata (entry points and such).
I'm not sure what PEP 517 has to say about this approach. In particular, would implementing this mean that the project would implementing building sdists, editable wheels, and metadata, but not wheels?
This weekend, I had an epiphany.
One of the major pain points for any build backend is adopting dependencies (https://github.com/pypa/packaging-problems/issues/342). As soon as any backend adds a dependency that's not built on flit-core, it runs into a cyclic dependency on itself and breaks source-only builds.
coherent.buildhits this cycle on the first loop -coherent.buildrequirescoherent.buildto build.Setuptools "solves" this problem by vendoring all of its dependencies, though it wishes not to do so. Hatchling "solves" this problem incidentally by only having dependencies on projects that use
flit-coreorsetuptools. If any of its dependencies were to adopt hatchling or if any of their dependencies were to adopt hatchling, it would have a circular dependency.coherent.builddoesn't solve this problem (source-only builds are broken).flit-coresolves the problem by implementing the whole of its functionality on the stdlib (a suitable approach, but doesn't generalize).But it occurred to me - what if
coherent.build, instead of producing sdists that depend oncoherent.build, built its sdists to rely onflit-core. That is, all of the complicated work that relies on dependencies is in the "discovery" of metadata, and all of the metadata is materialized in the sdist.coherent.buildcould produce sdists that use a different build backend that merely copies the files and metadata into a wheel.This approach would mean that system integrators and build frontends could install coherent projects from source with nothing but flit-core.
PEP 621 provides a way to provide the metadata (entry points and such).
I'm not sure what PEP 517 has to say about this approach. In particular, would implementing this mean that the project would implementing building sdists, editable wheels, and metadata, but not wheels?