Hi Robert, I don’t have a lot of time, so here’s a “hot take” on the points you bring up.
Robert Vollmert <[email protected]> writes: > On 13. Jun 2019, at 16:25, Timothy Sample <[email protected]> wrote: >> >>> I remembered one more: guix refresh. As far as I understand, it works >>> only on the level of the source field, thus having the revision there >>> would help make it revision-aware. I’m unsure though whether the >>> snippet approach actually improves things here — probably the refresh >>> code would see the resulting gexp and not the raw data. >> >> This is a very good point! Unfortunately, AFAICT, the refresh mechanism >> only works on the level of versions. It has no support for automated >> patches or snippet changes. It looks like updating the Cabal revision >> using the refresh script would require one or two far-reaching changes. >> Are there other package repositories that use a release-with-patches >> style? Having another example would make it easier to design at the >> right level of abstraction. >> >> Now I think that we should have a good plan for refreshing before making >> a bunch of changes to the Cabal revision stuff. Otherwise, we might >> have to change everything again if and when we make refreshing work. >> >> Thoughts? > > I agree that reworking the revision thing shouldn’t happen first. I’m > happy to understand how it might work for now. > > Is “guix refresh” even a good approach for the haskell packages? There’s > a lot of work being done to put consistent sets of haskell packages, e.g. > the whole stackage project. Does Guix mean to replicate this work, or would > it maybe be a good choice to follow stackage sets? We mostly do this already. There is a Stackage importer, and a little while ago I updated most of our Haskell packages to their LTS 12 versions. > How big is the diff between the current haskell package definitions and > the result of guix hackage import? It would be tempting to consider most > as an output of guix hackage import, and to refresh them by reimporting, > possibly based on a version set pulled from stackage. IIRC, Nix automatically imports all Haskell packages from Hackage (I’m a little fuzzy on the details, though). Our refresh script knows about Stackage, so you can use it to keep packages up to date with Stackage. One of the main issues with automatic package maintenance in Guix is that we have some unconventional, non-technical and semi-technical requirements on our packages. We need to follow the FSDG (Free Software Distribution Guidelines); we try and make sure that everything has a useful synopsis and description; and we try to make sure everything is bootstrappable and reproducible. I say “unconventional” above because there are often upstream issues with these things that need to be fixed manually. The reason I bring these up is that we would have to develop some mechanism to maintain documentation changes, extra license information, and any other changes we make. Basically, we can’t “just” reimport every time. I also worry that trying to move in that direction would result in less care taken to maintain our own standards of quality, since the tools would put pressure on us to just use whatever we get from upstream. This is just me thinking out loud, of course. > Hmm another tangential question: Is there any particular system to the > splitting of gnu/packages/haskell*.scm? Not beyond the obvious one (that is, crypto packages go in “crypto”). > haskell.scm itself is huge — does this have performance implications? Yes. It is an ongoing problem with Guix, and one of the reasons we split up the files in the first place. If you want to know more, there have been many discussions on this list. > I’ve been > wondering whether guile scales well with module size. It appears that circular > imports between package modules are not a problem? Personally I’d like to > see the haskell compiler in a different module from hackage modules. We are moving towards this in general. The “guile.scm” and “guile-xyz.scm” split is a recent example of this. > Other > than that, keeping our own categorization seems wasteful, why not one > haskell-hackage.scm that’s sorted alphabetically by package name? The subcategories (e.g., “web”) are mostly for performance reasons, AIUI. I’m not sure why packages are not alphabetical. I don’t think there is any formal organization to the packages within modules. Hope that helps! -- Tim
