Chris Marusich <cmmarus...@gmail.com> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Beside, related to Chris’ comment, I’m a bit concerned about versioning >> in such a widely distributed repo. The package graph in Guix has zero >> degrees of liberty: every package is connected to other packages; every >> Guix user sees the exact same graph. >> >> Here, we’d have to be more flexible and allow potluck.scm files to just >> say “import guile” or “import guile@2.0”; “import guile” might provide >> 2.0 on a machine running an older Guix, and it might give 2.2.9 on an >> up-to-date machine. >> >> IOW, we’re no longer describing one specific graph, but instead >> describing a family of graphs with some constraints. The benefits are >> decentralization, but the main drawback is non-reproducibility: the >> result would depend on the user machine’s initial state. >> >> To work around that, I think the server should resolve package >> specifications when the potluck.scm file is submitted, and insert each >> package in the Guix package graph of the moment. Does that make sense? >> Maybe that’s what you were describing when you talk about rewriting >> potluck.scm files so? > > When you say "insert each package in the Guix package graph," do you > mean, "add the package definition to the Guix source tree"?
No no, it’s a separate source tree. I mean add the potluck packages to the graph as per GUIX_PACKAGE_PATH. > What if "the potluck" maintained a pointer to the version (i.e., the > commit) of the Guix package definitions that it uses as its "base"? > From time to time, the potluck could update its pointer to point to a > more recent version of Guix's package definitions. In this way, every > version of the potluck would precisely specify the dependencies of all > the packages in that version of the potluck, including any transitive > dependencies that ultimately come from the official Guix package > definitions (as defined in the "base" version); there would be no > surprising version drift. I wonder if that would work? Then there’s the problem that Mark pointed out earlier, which is that it would force users to use a specific set of dependencies, possibly not current, when using the potluck. I think it’s nicer if both repos are decoupled, although that means we have to pay attention to version issues when the potluck is referring to packages provided by Guix. > What if someone wants to add a package definition to the Guix source > tree which depends on a package that is defined in the potluck? I guess we wouldn’t allow that in the Guix repo proper. Ludo’.
