From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Lirzin Subject: Re: 'guix environment' as a build tool. Date: Sun, 31 Jul 2016 06:17:08 +0200 Message-ID: <8737mqjvaz.fsf@gnu.org> 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]:57584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTiBr-0004vo-50 for guix-devel@gnu.org; Sun, 31 Jul 2016 00:17:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTiBo-00041k-Uo for guix-devel@gnu.org; Sun, 31 Jul 2016 00:17:26 -0400 In-Reply-To: (David Thompson's message of "Sat, 30 Jul 2016 22:20:42 -0400") 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: "Thompson, David" Cc: guix-devel "Thompson, David" writes: > 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 s= qlite 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 insta= ll >>>> 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 coul= d 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. Obviously I disagree. >> - the origin hash doesn't make sense. > > You don't need one. Use local-file for the source field. I would be happy to, however I vaguely remember trying this without success for Mcron. Do you have an example to provide? >> - packages already included in Guix have redundant description and syno= psis. > > I don't understand what this means. > >> - package definitions rely on Guix internals. > > The package API rarely changes in practice. This is relative, IME packages moving across modules is not an exception. >> 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. Since this script is supposed to be wrapper around 'guix environment' I don't understand how it could limit anything 'guix environment' could do? > Also, with a package file, Guix users can install the development > snapshot with 'guix package -f' or simply build it with 'guix build > -f'. I am not sure what you mean by "development snapshot". If you an arbitrary timely chosen commit like what is done for Haunt: (origin (method git-fetch) (uri (git-reference (url "git://dthompson.us/haunt.git") (commit "f0a7c2b14a201448432d3564d851ee0686d5b1b1"))) (sha256 (base32 "1dnzsw18blhr8admw48zbl3ilz3iiqmb149i37y820h0imqfli0v")))) This is not useful for me. In most case I want 'guix build -f' to build the current commit from the local repository. If 'local-file' can work then this is fine, but I have never achieved the expected result. >> 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. That would be nice. > Hopefully this clears things up Maybe I am misinterpreting, but this read a bit patronizing. No need to say that if this is the case I don't appreciate much. --=20 Mathieu Lirzin