| Message ID | 871rw88u5s.fsf@gnu.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#37478] Support canonical guix environment -l guix.scm. | expand |
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’.
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> 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.
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
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
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))))
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(-)