[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Jan Nieuwenhuizen]

Hi Guix,

I often find myself typing `guix environment -l guix.scm' in the Guix
source root and thought IWBN no make that "just work".  WYDT?

Greetings,
janneke

From 18f1ef75d38c8a40d2e1f8d56a041cd64bc5c64f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 22 Sep 2019 13:01:38 +0200
Subject: [PATCH] Support canonical guix environment -l guix.scm.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Developers are encouraged to include a `guix.scm' in the root of their project
source to set-up a development environment (See 4.2 Invoking ‘guix package’),
so that

    guix environment -l guix.scm

provides a development environment.

* guix.scm: Return guix "git" package.
---
 guix.scm | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/guix.scm b/guix.scm
index 8753c21e42..919179e5cf 100644
--- a/guix.scm
+++ b/guix.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2014 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -16,7 +17,11 @@
 ;;; You should have received a copy of the GNU General Public License
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
-(define-module (guix))
+(define-module (guix)
+  #:use-module (guix git-download)
+  #:use-module (guix gexp)
+  #:use-module (guix packages)
+  #:use-module (gnu packages package-management))
 
 ;; The composite module that re-exports everything from the public modules.
 
@@ -39,3 +44,25 @@
                 (lambda (m)
                   (module-use! i (resolve-interface `(guix ,m)))))
               %public-modules)))
+
+;; To setup the development environment, run the following:
+;;
+;;    guix environment -l guix.scm
+;;    ./bootstrap && ./configure;
+;;
+;; To build the development snapshot, run:
+;;
+;;    guix build -f guix.scm
+;;
+;; To install the development snapshot, run:
+;;
+;;    guix package -f guix.scm
+;;
+(define %source-dir (dirname (current-filename)))
+
+(package
+  (inherit guix)
+  (version "git")
+  (source (local-file %source-dir
+                      #:recursive? #t
+                      #:select? (git-predicate %source-dir))))
-- 
2.23.0

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Ludovic Courtès]

Hello,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> I often find myself typing `guix environment -l guix.scm' in the Guix
> source root and thought IWBN no make that "just work".  WYDT?

IWBN, but…

> -(define-module (guix))
> +(define-module (guix)
> +  #:use-module (guix git-download)
> +  #:use-module (guix gexp)
> +  #:use-module (guix packages)
> +  #:use-module (gnu packages package-management))

… the (guix) module is a public module, and it must not depend on
anything but the (guix …) modules it imports.

So unfortunately we can’t just do that.

Perhaps we could have a ‘.guix.scm’ file though, or
‘build-aux/guix.scm’, something like that?

Thanks,
Ludo’.

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> I often find myself typing `guix environment -l guix.scm' in the Guix
>> source root and thought IWBN no make that "just work".  WYDT?
>
> IWBN, but…
>
>> -(define-module (guix))
>> +(define-module (guix)
>> +  #:use-module (guix git-download)
>> +  #:use-module (guix gexp)
>> +  #:use-module (guix packages)
>> +  #:use-module (gnu packages package-management))
>
> … the (guix) module is a public module, and it must not depend on
> anything but the (guix …) modules it imports.
>
> So unfortunately we can’t just do that.

Hmm, and is there a difference between compile-time and run-time?  I do
not understand the rules well enough here...

So I guess that something vaguely this (I really don't like the
command-line "parsing" bit, just a thought experiment)

--8<---------------cut here---------------start------------->8---
;; Naive command-line parser: are we running from Guix source tree
;;    guix build -f guix.scm
;;    guix environment -l guix.scm
;; then return guix@git package
(when (and (file-exists? "guix/gexp.scm")
           (let ((len (length (command-line))))
             (and (> len 3)
                  (let ((tail (list-tail (command-line) (- len 3))))
                    (or (equal? tail '("build" "-f" "guix.scm"))
                        (equal? tail '("environment" "-l" "guix.scm")))))))
  (let ((source-dir (dirname (current-filename))))
    ((@ (guix packages) package)
     (inherit (@ (gnu packages package-management) guix))
     (version "git")
     (source ((@ (guix gexp) local-file) source-dir
              #:recursive? #t
              #:select? ((@ (guix git-download) git-predicate) source-dir))))))
--8<---------------cut here---------------end--------------->8---

is also not possible?  It is also starts to look like a kludge and hard
to get right...bah :)

> Perhaps we could have a ‘.guix.scm’ file though, or
> ‘build-aux/guix.scm’, something like that?

Yes...I was hoping that we could offer/advise something standardized
that all guix'ified upstreams could/would use.  I think that I've seen
`.guix.scm', but also a `guix.scm' that returns a manifest, so usage
would be `guix environment -m guix.scm', and no way to build the package
itself from git.

Once Guix is blessed `the GNU System' (any day now ;-) we need to have a
a thought-through proposal to amend standards.texi anyway.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Brett Gilio]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Ludovic Courtès writes:
>
>>> I often find myself typing `guix environment -l guix.scm' in the Guix
>>> source root and thought IWBN no make that "just work".  WYDT?
>>
>> IWBN, but…
>>
>>> -(define-module (guix))
>>> +(define-module (guix)
>>> +  #:use-module (guix git-download)
>>> +  #:use-module (guix gexp)
>>> +  #:use-module (guix packages)
>>> +  #:use-module (gnu packages package-management))
>>
>> … the (guix) module is a public module, and it must not depend on
>> anything but the (guix …) modules it imports.
>>
>> So unfortunately we can’t just do that.
>
> Hmm, and is there a difference between compile-time and run-time?  I do
> not understand the rules well enough here...
>
> So I guess that something vaguely this (I really don't like the
> command-line "parsing" bit, just a thought experiment)
>
> ;; Naive command-line parser: are we running from Guix source tree
> ;;    guix build -f guix.scm
> ;;    guix environment -l guix.scm
> ;; then return guix@git package
> (when (and (file-exists? "guix/gexp.scm")
>            (let ((len (length (command-line))))
>              (and (> len 3)
>                   (let ((tail (list-tail (command-line) (- len 3))))
>                     (or (equal? tail '("build" "-f" "guix.scm"))
>                         (equal? tail '("environment" "-l" "guix.scm")))))))
>   (let ((source-dir (dirname (current-filename))))
>     ((@ (guix packages) package)
>      (inherit (@ (gnu packages package-management) guix))
>      (version "git")
>      (source ((@ (guix gexp) local-file) source-dir
>               #:recursive? #t
>               #:select? ((@ (guix git-download) git-predicate) source-dir))))))
>
> is also not possible?  It is also starts to look like a kludge and hard
> to get right...bah :)
>
>> Perhaps we could have a ‘.guix.scm’ file though, or
>> ‘build-aux/guix.scm’, something like that?
>
> Yes...I was hoping that we could offer/advise something standardized
> that all guix'ified upstreams could/would use.  I think that I've seen
> `.guix.scm', but also a `guix.scm' that returns a manifest, so usage
> would be `guix environment -m guix.scm', and no way to build the package
> itself from git.
>
> Once Guix is blessed `the GNU System' (any day now ;-) we need to have a
> a thought-through proposal to amend standards.texi anyway.
>
> Greetings,
> janneke

Hey all, where are we standing with this currently? I think there has
been some recent revisions with how we are using the `-l` flag, and want
to see if this still needs to some work. I am happy to offer my help.

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Thompson, David]

Hi,

On Mon, Dec 9, 2019 at 11:53 PM Brett Gilio <brettg@posteo.net> wrote:
>
> Hey all, where are we standing with this currently? I think there has
> been some recent revisions with how we are using the `-l` flag, and want
> to see if this still needs to some work. I am happy to offer my help.

I think it would be great if y'all could come to a consensus on a
canonical Guix environment file name (shortly after writing 'guix
environment' I started using 'guix.scm' files in the root of my
project repos in lieu of any convention) and, additionally, establish
whether that file evaluates to a package or to a manifest (or maybe it
could be either!)  I will change my project repos to conform to the
established convention.

To elaborate a bit on the choices, I've discovered there are pros and
cons to -l and -m and I've flip-flopped on which I liked better, but
today I find manifests to be the better option for the "I just cloned
a repo and want to build a dev environment" use-case.  Most of my
project environments are created via 'guix environment -l guix.scm'
and the contents of 'guix.scm' look something like this:

    (package
      (name "chickadee")
      (version "0.1")
      (source #f)
      (build-system gnu-build-system)
      (native-inputs
       `(("autoconf" ,autoconf)
         ("automake" ,automake)
         ("pkg-config" ,pkg-config)
         ("texinfo" ,texinfo)))
      (inputs
       `(("guile" ,target-guile)
         ("libvorbis" ,libvorbis)
         ("openal" ,openal)))
      (propagated-inputs
       `(("guile-opengl" ,guile-opengl)
         ("guile-sdl2" ,guile-sdl2)))
      (synopsis "Game development toolkit for Guile Scheme")
      (description "Chickadee is a game development toolkit for Guile
    Scheme.  It contains all of the basic components needed to develop
    2D/3D video games.")
      (home-page "https://dthompson.us/projects/chickadee.html")
      (license gpl3+))

Initially I thought a package made sense because, in addition to being
used as the basis of a dev environment, I could build the same file as
part of a CI system or pre-release make target, but in practice I
can't really do that, thus the '(source #f)' bit and all the other
boilerplate like version, synopsis, description, and license fields to
satisfy the syntax rules.  It's also not a suitable package for
upstreaming to Guix later because building from git requires
additional dependencies that aren't needed when building from a
release tarball.  So, if I were to rewrite this file today, I think I
would just make a manifest instead.

Of course, Guix could also just eval the file, use package? and
manifest? predicates to see what it got, and act accordingly.  That
might be the best choice from a usability standpoint.

- Dave

[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Jan Nieuwenhuizen]

Thompson, David writes:

>     (package
>       (name "chickadee")
>       (version "0.1")
>       (source #f)
[..]

> Initially I thought a package made sense because, in addition to being
> used as the basis of a dev environment, I could build the same file as
> part of a CI system or pre-release make target, but in practice I
> can't really do that, thus the '(source #f)' bit and all the other
> boilerplate like version, synopsis, description, and license fields to
> satisfy the syntax rules.  It's also not a suitable package for
> upstreaming to Guix later because building from git requires
> additional dependencies that aren't needed when building from a
> release tarball.  So, if I were to rewrite this file today, I think I
> would just make a manifest instead.
>
> Of course, Guix could also just eval the file, use package? and
> manifest? predicates to see what it got, and act accordingly.  That
> might be the best choice from a usability standpoint.

Interesting!  I've been flipping here too.  Currently, I am using a
split setup.  The upstream(able) package lives in a subdirectory

--8<---------------cut here---------------start------------->8---
;;; guix/git/mes.scm:
(define-module (git mes)

(define-public mes
  (let ((triplet "i686-unknown-linux-gnu")
        (version "0.21"))
    (package
      (name "mes")
      (version version)
      (source (origin
                (method url-fetch)
                (uri (string-append
                      "https://ftp.gnu.org/pub/gnu/mes/mes-" version ".tar.gz"))
                (sha256
                 (base32 "04pajp8v31na34ls4730ig5f6miiplhdvkmsb9ls1b8bbmw2vb4n"))))
      (build-system gnu-build-system)
      ...
      (home-page "https://www.gnu.org/software/mes")
      (license gpl3+))))
--8<---------------cut here---------------end--------------->8---

and my guix.scm then uses that

--8<---------------cut here---------------start------------->8---
;;; guix.scm
(use-modules (guix gexp)
             (guix git-download)
             (guix packages)
             (gnu packages))

(define %source-dir (dirname (current-filename)))
(add-to-load-path (string-append %source-dir "/guix"))
(use-modules (git mes))

(define-public mes.git
  (package
    (inherit mes)
    (source (local-file %source-dir
                        #:recursive? #t
                        #:select? (git-predicate %source-dir)))))

mes.git
--8<---------------cut here---------------end--------------->8---

This way, I can maintain an upstream(able) package literally, build
from git and have my environment set up.

As a bonus, you can then use a .guix-channel file
--8<---------------cut here---------------start------------->8---
(channel
 (version 0)
 (directory "guix"))
--8<---------------cut here---------------end--------------->8---

so that you can guix pull straight from your repo.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com