From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: on cabal revisions Date: Fri, 14 Jun 2019 11:36:04 -0400 Message-ID: <87d0jgnpqz.fsf@ngyro.com> References: <87v9xbmmid.fsf@ngyro.com> <87r27xa7f0.fsf@ngyro.com> <2CEDD93D-5200-4B3E-AA2E-BA1FE6168B40@vllmrt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56364) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hboHi-0003rh-HG for guix-devel@gnu.org; Fri, 14 Jun 2019 11:38:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hboFM-0006Tz-NC for guix-devel@gnu.org; Fri, 14 Jun 2019 11:36:09 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:34839) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hboFM-0006Sh-HJ for guix-devel@gnu.org; Fri, 14 Jun 2019 11:36:08 -0400 In-Reply-To: <2CEDD93D-5200-4B3E-AA2E-BA1FE6168B40@vllmrt.net> (Robert Vollmert's message of "Fri, 14 Jun 2019 16:30:25 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Robert Vollmert Cc: guix-devel@gnu.org Hi Robert, I don=E2=80=99t have a lot of time, so here=E2=80=99s a =E2=80=9Chot take= =E2=80=9D on the points you bring up. Robert Vollmert writes: > On 13. Jun 2019, at 16:25, Timothy Sample wrote: >>=20 >>> 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=E2=80=99m unsure though whether the >>> snippet approach actually improves things here =E2=80=94 probably the r= efresh >>> code would see the resulting gexp and not the raw data. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thoughts? > > I agree that reworking the revision thing shouldn=E2=80=99t happen first.= I=E2=80=99m > happy to understand how it might work for now. > > Is =E2=80=9Cguix refresh=E2=80=9D even a good approach for the haskell pa= ckages? There=E2=80=99s > 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 wou= ld > 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=E2=80= =99m 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 =E2=80=9Cunconventional=E2=80=9D above because the= re 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=E2=80=99t =E2=80=9Cjust= =E2=80=9D 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 =E2=80=9Ccrypto= =E2=80=9D). > haskell.scm itself is huge =E2=80=94 does this have performance implicati= ons? 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=E2=80=99ve been > wondering whether guile scales well with module size. It appears that cir= cular > imports between package modules are not a problem? Personally I=E2=80=99d= like to > see the haskell compiler in a different module from hackage modules. We are moving towards this in general. The =E2=80=9Cguile.scm=E2=80=9D and =E2=80=9Cguile-xyz.scm=E2=80=9D split is a recent example of this. > Other > than that, keeping our own categorization seems wasteful, why not one > haskell-hackage.scm that=E2=80=99s sorted alphabetically by package name? The subcategories (e.g., =E2=80=9Cweb=E2=80=9D) are mostly for performance = reasons, AIUI. I=E2=80=99m not sure why packages are not alphabetical. I don=E2=80= =99t think there is any formal organization to the packages within modules. Hope that helps! -- Tim