From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Vollmert Subject: Re: on cabal revisions Date: Fri, 14 Jun 2019 16:30:25 +0200 Message-ID: <2CEDD93D-5200-4B3E-AA2E-BA1FE6168B40@vllmrt.net> References: <87v9xbmmid.fsf@ngyro.com> <87r27xa7f0.fsf@ngyro.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:34145) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbnEQ-0004Y9-DK for guix-devel@gnu.org; Fri, 14 Jun 2019 10:31:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbnEN-000231-Kq for guix-devel@gnu.org; Fri, 14 Jun 2019 10:31:06 -0400 Received: from mx1.mailbox.org ([2001:67c:2050:104:0:1:25:1]:14050) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hbnEN-0001jg-9l for guix-devel@gnu.org; Fri, 14 Jun 2019 10:31:03 -0400 In-Reply-To: <87r27xa7f0.fsf@ngyro.com> 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: Timothy Sample Cc: guix-devel@gnu.org 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 = refresh >> 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 = packages? 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 = would it maybe be a good choice to follow stackage sets? 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. Hmm another tangential question: Is there any particular system to the splitting of gnu/packages/haskell*.scm? haskell.scm itself is huge =E2=80=94 does this have performance = implications? I=E2=80=99ve been wondering whether guile scales well with module size. It appears that = circular 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. = Other than that, keeping our own categorization seems wasteful, why not one haskell-hackage.scm that=E2=80=99s sorted alphabetically by package = name? Robert