[PATCH] Support canonical guix environment -l guix.scm.

OpenSubmitted by Jan Nieuwenhuizen.
Details
4 participants
  • Brett Gilio
  • Thompson, David
  • Jan Nieuwenhuizen
  • Ludovic Courtès
Owner
unassigned
Severity
normal
J
J
Jan Nieuwenhuizen wrote on 22 Sep 2019 13:09
(address . guix-patches@gnu.org)
871rw88u5s.fsf@gnu.org
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(-)

Toggle diff (56 lines)
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
L
L
Ludovic Courtès wrote on 25 Sep 2019 15:28
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 37478@debbugs.gnu.org)
871rw4mro9.fsf@gnu.org
Hello,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (3 lines)
> 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…

Toggle quote (7 lines)
> -(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’.
J
J
Jan Nieuwenhuizen wrote on 5 Oct 2019 11:25
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37478@debbugs.gnu.org)
87k19jy26l.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (17 lines)
>> 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)

Toggle snippet (19 lines)
;; 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 :)

Toggle quote (3 lines)
> 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
B
B
Brett Gilio wrote on 10 Dec 2019 05:52
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
874ky8n5nw.fsf@posteo.net
Jan Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (61 lines)
> 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/
T
T
Thompson, David wrote on 10 Dec 2019 19:45
(name . Brett Gilio)(address . brettg@posteo.net)
CAJ=RwfYvSNmuRnuxh3_szybFw1ucEYDsZJK8w1eqaXBe9kQBuw@mail.gmail.com
Hi,

On Mon, Dec 9, 2019 at 11:53 PM Brett Gilio <brettg@posteo.net> wrote:
Toggle quote (5 lines)
>
> 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.")
(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
J
J
Jan Nieuwenhuizen wrote on 10 Dec 2019 21:59
(name . Thompson, David)(address . dthompson2@worcester.edu)
87a77z7v85.fsf@gnu.org
Thompson, David writes:

Toggle quote (4 lines)
> (package
> (name "chickadee")
> (version "0.1")
> (source #f)
[..]

Toggle quote (15 lines)
> 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

Toggle snippet (21 lines)
;;; 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+))))

and my guix.scm then uses that

Toggle snippet (20 lines)
;;; 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

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
Toggle snippet (5 lines)
(channel
(version 0)
(directory "guix"))

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
?