From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: =?UTF-8?Q?Re=3A_=27guix_environment=27_as_a_build_tool=2E_=28was=3A_=5BGSoC=5D?= =?UTF-8?Q?_Continuous_integration_tool_=C3=A0_la_Hydra=2E=29?= Date: Sat, 30 Jul 2016 22:20:42 -0400 Message-ID: References: <871t4ksk0n.fsf@gnu.org> <87vazueezx.fsf@gnu.org> <87lh0pe6y7.fsf@gnu.org> <87invockk7.fsf@gnu.org> <87wpk291wo.fsf@gnu.org> <877fc2k1ei.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTgMw-0002S5-K0 for guix-devel@gnu.org; Sat, 30 Jul 2016 22:20:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTgMu-0006wP-Cj for guix-devel@gnu.org; Sat, 30 Jul 2016 22:20:45 -0400 Received: from mail-ua0-x229.google.com ([2607:f8b0:400c:c08::229]:34889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTgMu-0006wG-67 for guix-devel@gnu.org; Sat, 30 Jul 2016 22:20:44 -0400 Received: by mail-ua0-x229.google.com with SMTP id l32so85759285ual.2 for ; Sat, 30 Jul 2016 19:20:43 -0700 (PDT) In-Reply-To: <877fc2k1ei.fsf_-_@gnu.org> 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: Mathieu Lirzin Cc: guix-devel On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin wrote: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Mathieu Lirzin skribis: >> >>> I have tested successfully with the following command on a foreign >>> system: >>> >>> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sq= lite guile-sqlite3 >>> >>> Tell me if it works for you. >>> >>>> How about including a guix package definition then we can easily build >>>> it assuming "we" know how to do out-of-guix-tree package building :) >>> >>> It would indeed be nice to provide an easy way for Guix users to instal= l >>> Cuirass. IMHO package definitions meant as a development build tool is >>> confusing and should be avoided. Nonetheless, I think it is useful to >>> document the previous 'guix environment ...' command in the README. >> >> What about providing a =E2=80=98guix.scm=E2=80=99 file that people could= pass to =E2=80=98guix >> environment -l=E2=80=99 (instead of typing the long command above), and = to =E2=80=98guix >> package -f=E2=80=99 (info "(guix) Invoking guix package")? > > 'guix environment -l' uses a package definition. To me this abstraction > doesn't fit well in a development context: It *does* fit well. This use-case is why I wrote 'guix environment' in the first place. > - the origin hash doesn't make sense. You don't need one. Use local-file for the source field. > - packages already included in Guix have redundant description and synop= sis. I don't understand what this means. > - package definitions rely on Guix internals. The package API rarely changes in practice. > In fact what 'guix.scm' contains feels more like a "debian" directory or > a "PACKAGE.spec" file on steroid because of the "guix environment -l" > feature which derives from it but doesn't appear as first class. > > An idea that I like better and is less invasive, would be to complement > bootstrap scripts with: > > ./bootstrap --with-guix > > This command would: > > - generate a guix-env script that wraps 'guix environment ...' if it > doesn't exist. > - Invoke ./guix-env > - Invoke autoreconf -vfi > > if the user wants to enter this environment Later it will have to invoke > './guix-env'. This just makes things more inconvenient and limits potential utility. You would lose the ability to tweak the dependency graph with custom package recipes. I do this frequently in my projects that use bleeding edge features of other software that may not even have an official release yet. Also, with a package file, Guix users can install the development snapshot with 'guix package -f' or simply build it with 'guix build -f'. > Some interesting things could be done beyond this, for example by using > per repository profiles that would save development environments. This > would allow developpers to easily use different setups. 'guix environment' already serves this purpose. I do want to extend 'guix environment' with a --save flag that will register the profile it generates as a GC root so that it can be saved for future sessions so that the environment doesn't need to be rebuilt every time the user upgrades Guix. Hopefully this clears things up. - Dave