Hi, Mark H Weaver <m...@netris.org> writes:
> Pjotr Prins <pjotr.publi...@thebird.nl> writes: > >> How about the following: >> >> 1. Separate from the GNU project, we create a number of registries of >> online git repos without opinion (i.e., anything goes, it is up to >> the authors). A registry can contain the work of multiple packages >> and multiple authors. >> >> 2. Each repo in the registry can create package definitions online > > The major problem with this proposal is that, to the extent it became > popular, it would drastically reduce the freedom we have to change Guix > itself. We would need to start considering whether our changes might > break externally maintained packages. A large proportion of our > internal procedures and macros would effectively become a public API. > We would no longer be able to freely make changes to the way packages > are specified, or make incompatible changes to the procedures and macros > used in package definitions on the client or build sides. We would be > greatly constrained in our ability to make changes to the default phases > in our build systems. > > Our core packages and most of our library packages would also > effectively be part of this API. We would no longer be able to freely > do things like split packages into smaller pieces or multiple outputs. > > Long ago, the Linux developers made a conscious decision to not support > out-of-tree drivers, for much the same reasons. Many times over the > years, they have made changes to their internal APIs that required > corresponding changes to a large number of drivers. As a result, they > have been able to keep their internal interfaces clean and free of > backward-compatibility cruft. > > It's crucially important to the future vitality of this project that we > retain our freedom to evolve the design of Guix, the way packages are > specified in Guix, as well as the set of core packages. These freedoms > will be drastically curtailed if we support a decentralized system of > externally-managed repositories. Therefore, we must not do this. > > What do other people think? I fully agree with everything you said. When acknowledging all the consequences of providing a public API for package definitions, the main goal of lowering the barrier to entry is missed because everything becomes more complex. -- Mathieu Lirzin
