Adding JPM package for Janet

  • Open
  • quality assurance status badge
Details
4 participants
  • jgart
  • Ludovic Courtès
  • Omar Bassam
  • Suhail Singh
Owner
unassigned
Submitted by
Omar Bassam
Severity
normal
O
O
Omar Bassam wrote on 1 Sep 10:31 +0200
(address . guix-patches@gnu.org)
CAGSr2raCcjZJPcuHxajxrys+Zjap2etc3KHgLn_J+SENYEZ5eQ@mail.gmail.com
From 14fd8cafaebc27a00a4b198abe8e3759583c56b5 Mon Sep 17 00:00:00 2001
Message-ID: <
14fd8cafaebc27a00a4b198abe8e3759583c56b5.1725179146.git.omar.bassam88@gmail.com
Toggle quote (1 lines)
>
From: Omar Bassam <omar.bassam88@gmail.com>
Date: Sun, 1 Sep 2024 08:17:08 +0000
Subject: [PATCH] adding jpm package

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 52 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

Toggle diff (83 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 5d4399f145..4d4748dcb4 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,57 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))

+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32
"05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system trivial-build-system)
+ (arguments
+ (list
+ #:modules `((guix build utils))
+ #:builder #~(begin
+ (use-modules (guix build utils))
+ (mkdir %output)
+ (for-each (lambda (dir) (mkdir (string-append %output
"/" dir)))
+ '("bin" "lib" "share" "share/man" "lib/janet"
+ "lib/janet/jpm" "share/man/man1"))
+ (copy-recursively (assoc-ref %build-inputs "source")
"source")
+ (chdir "source")
+ (substitute* "configs/linux_config.janet"
+ (("auto-shebang true") "auto-shebang false"))
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") %output))
+ (substitute* "jpm/shutil.janet"
+ (("cp") (string-append #$coreutils "/bin/cp")))
+ (substitute* "jpm/declare.janet"
+ (("chmod") (string-append #$coreutils "/bin/chmod")))
+ (setenv "PREFIX" %output)
+ (setenv "JANET_PREFIX" %output)
+ (setenv "JANET_LIBPATH" (string-append %output
"/lib/janet"))
+ (setenv "JANET_MODPATH" (string-append %output
"/lib/janet"))
+ (system* (string-append #$janet "/bin/janet")
+ "bootstrap.janet"
"configs/linux_config.janet")
+ (substitute* (string-append %output "/bin/jpm")
+ (("/usr/bin/env janet")
+ (string-append #$janet "/bin/janet")))
+ (copy-recursively (string-append #$janet
"/include/janet")
+ (string-append %output
"/include/janet"))
+ (copy-recursively (string-append #$janet "/lib")
+ (string-append %output "/lib")))))
+ (inputs (list janet coreutils))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for
automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: e05f0e9832326703fa90a02559f1a4b44e4401ad
--
2.45.2
Attachment: file
O
O
Omar Bassam wrote on 4 Sep 10:22 +0200
[PATCH] adding jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
14fd8cafaebc27a00a4b198abe8e3759583c56b5.1725179146.git.omar.bassam88@gmail.com
Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 52 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

Toggle diff (74 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 5d4399f145..4d4748dcb4 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,57 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system trivial-build-system)
+ (arguments
+ (list
+ #:modules `((guix build utils))
+ #:builder #~(begin
+ (use-modules (guix build utils))
+ (mkdir %output)
+ (for-each (lambda (dir) (mkdir (string-append %output "/" dir)))
+ '("bin" "lib" "share" "share/man" "lib/janet"
+ "lib/janet/jpm" "share/man/man1"))
+ (copy-recursively (assoc-ref %build-inputs "source") "source")
+ (chdir "source")
+ (substitute* "configs/linux_config.janet"
+ (("auto-shebang true") "auto-shebang false"))
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") %output))
+ (substitute* "jpm/shutil.janet"
+ (("cp") (string-append #$coreutils "/bin/cp")))
+ (substitute* "jpm/declare.janet"
+ (("chmod") (string-append #$coreutils "/bin/chmod")))
+ (setenv "PREFIX" %output)
+ (setenv "JANET_PREFIX" %output)
+ (setenv "JANET_LIBPATH" (string-append %output "/lib/janet"))
+ (setenv "JANET_MODPATH" (string-append %output "/lib/janet"))
+ (system* (string-append #$janet "/bin/janet")
+ "bootstrap.janet" "configs/linux_config.janet")
+ (substitute* (string-append %output "/bin/jpm")
+ (("/usr/bin/env janet")
+ (string-append #$janet "/bin/janet")))
+ (copy-recursively (string-append #$janet "/include/janet")
+ (string-append %output "/include/janet"))
+ (copy-recursively (string-append #$janet "/lib")
+ (string-append %output "/lib")))))
+ (inputs (list janet coreutils))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: e05f0e9832326703fa90a02559f1a4b44e4401ad
--
2.45.2
O
O
Omar Bassam wrote on 5 Sep 16:50 +0200
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
950a7d3637ddf17be84f52dc2ae0aac2ce4c4be6.1725547778.git.omar.bassam88@gmail.com
Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 52 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

Toggle diff (74 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 5d4399f145..96698d375d 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,57 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system trivial-build-system)
+ (arguments
+ (list
+ #:modules `((guix build utils))
+ #:builder #~(begin
+ (use-modules (guix build utils))
+ (mkdir %output)
+ (for-each (lambda (dir) (mkdir (string-append %output "/" dir)))
+ '("bin" "lib" "share" "share/man" "lib/janet"
+ "lib/janet/jpm" "share/man/man1"))
+ (copy-recursively (assoc-ref %build-inputs "source") "source")
+ (chdir "source")
+ (substitute* "configs/linux_config.janet"
+ (("auto-shebang true") "auto-shebang false"))
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") %output))
+ (substitute* "jpm/shutil.janet"
+ (("cp") (string-append #$coreutils "/bin/cp")))
+ (substitute* "jpm/declare.janet"
+ (("chmod") (string-append #$coreutils "/bin/chmod")))
+ (setenv "PREFIX" %output)
+ (setenv "JANET_PREFIX" %output)
+ (setenv "JANET_LIBPATH" (string-append %output "/lib/janet"))
+ (setenv "JANET_MODPATH" (string-append %output "/lib/janet"))
+ (system* (string-append #$janet "/bin/janet")
+ "bootstrap.janet" "configs/linux_config.janet")
+ (substitute* (string-append %output "/bin/jpm")
+ (("/usr/bin/env janet")
+ (string-append #$janet "/bin/janet")))
+ (copy-recursively (string-append #$janet "/include/janet")
+ (string-append %output "/include/janet"))
+ (copy-recursively (string-append #$janet "/lib")
+ (string-append %output "/lib")))))
+ (inputs (list janet coreutils))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: e05f0e9832326703fa90a02559f1a4b44e4401ad
--
2.45.2
S
S
Suhail Singh wrote on 18 Sep 15:18 +0200
Re: bug#72925: Adding JPM package for Janet
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87h6adyua5.fsf_-_@gmail.com
Hi Omar,

Thank you for submitting this patch. A few comments:

Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (8 lines)
> Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
> ---
> gnu/packages/lisp.scm | 52 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
> index 5d4399f145..96698d375d 100644

Could you please update the reroll-count when you send amendments to the
patch? IIUC, this version should have been v2.

Toggle quote (17 lines)
> +(define-public jpm
> + (package
> + (name "jpm")
> + (version "1.1.0")
> + (source (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/janet-lang/jpm.git")
> + (commit (string-append "v" version))))
> + (file-name (git-file-name name version))
> + (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
> + (build-system trivial-build-system)
> ...
> + (substitute* (string-append %output "/bin/jpm")
> + (("/usr/bin/env janet")
> + (string-append #$janet "/bin/janet")))

Is my understanding correct that you're updating the shebang line here?
If so, would it be better to use the copy-build-system instead? If not,
could you please elaborate? If copy-build-system does indeed turn out
to be better suited, could you please send v3 of the patch?

--
Suhail
S
S
Suhail Singh wrote on 18 Sep 15:28 +0200
control message for bug #72925
(address . control@debbugs.gnu.org)
87ed5hytt9.fsf@gmail.com
owner 72925 !
quit
S
S
Suhail Singh wrote on 18 Sep 18:16 +0200
Re: bug#72925: Adding JPM package for Janet
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87a5g5vswz.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (4 lines)
> Thank you for taking the time to look into my patch. Sorry, I'm new to Guix
> and to this workflow. So, forgive me if my questions look a bit naive:
> 1. What do you mean by reroll count for the patch?

Please refer to the man page of git-format-patch and look for
--reroll-count :

#+begin_quote
-v <n>, --reroll-count=<n>
Mark the series as the <n>-th iteration of the topic. The output
filenames have v<n> prepended to them, and the subject prefix
("PATCH" by default, but configurable via the --subject-prefix
option) has ` v<n>` appended to it. E.g. --reroll-count=4 may
produce v4-0001-add-makefile.patch file that has "Subject: [PATCH
v4 1/20] Add makefile" in it. <n> does not have to be an integer
(e.g. "--reroll-count=4.4", or "--reroll-count=4rev2" are allowed),
but the downside of using such a reroll-count is that the
range-diff/interdiff with the previous version does not state
exactly which version the new iteration is compared against.
#+end_quote

Toggle quote (6 lines)
> 2. I looked at the copy-build-system documentation. I'm not sure how it can
> be used here. I'm not just updating the shebang. As you can already see in
> the patch, I'm doing a lot of string substitutions in the source code
> itself because some values are hard coded. That's why I preferred to use
> the trivial-build-system to have more control of what I need to substitute.

Based on my understanding of the patch you are copying files, updating
some references in files, and setting environment variables. I believe
all of these are possible via the copy-build-system as well which is
described as:

#+begin_quote
;; Standard build procedure for simple packages that don't require much
;; compilation, mostly just copying files around. This is implemented as an
;; extension of `gnu-build-system'.
#+end_quote

If you'd like to learn more, you can grep under ./gnu/packages and look
at some instances where it's used. I don't have experience with the
trivial-build-system, which is why I wondered.

Toggle quote (5 lines)
> + (setenv "PREFIX" %output)
> + (setenv "JANET_PREFIX" %output)
> + (setenv "JANET_LIBPATH" (string-append %output "/lib/janet"))
> + (setenv "JANET_MODPATH" (string-append %output "/lib/janet"))

What would be a way to test that the above is doing the "correct" thing?
Is there a sequence of steps that I can evaluate which will yield a
different outcome depending on whether or not the above accomplishes
what it intends to? Put another way, what breaks when the above aren't
set (and how do I observe that failure)?

--
Suhail
O
O
Omar Bassam wrote on 18 Sep 17:34 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2raMWHraSs_y9wEbZr1vv_h5j3igZcDsppExjR6rH_U8FQ@mail.gmail.com
Thank you for taking the time to look into my patch. Sorry, I'm new to Guix
and to this workflow. So, forgive me if my questions look a bit naive:
1. What do you mean by reroll count for the patch?
2. I looked at the copy-build-system documentation. I'm not sure how it can
be used here. I'm not just updating the shebang. As you can already see in
the patch, I'm doing a lot of string substitutions in the source code
itself because some values are hard coded. That's why I preferred to use
the trivial-build-system to have more control of what I need to substitute.

Thanks,
Omar

On Wed, 18 Sept 2024 at 16:19, Suhail Singh <suhailsingh247@gmail.com>
wrote:

Toggle quote (43 lines)
> Hi Omar,
>
> Thank you for submitting this patch. A few comments:
>
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
> > ---
> > gnu/packages/lisp.scm | 52 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
> > index 5d4399f145..96698d375d 100644
>
> Could you please update the reroll-count when you send amendments to the
> patch? IIUC, this version should have been v2.
>
> > +(define-public jpm
> > + (package
> > + (name "jpm")
> > + (version "1.1.0")
> > + (source (origin
> > + (method git-fetch)
> > + (uri (git-reference
> > + (url "https://github.com/janet-lang/jpm.git")
> > + (commit (string-append "v" version))))
> > + (file-name (git-file-name name version))
> > + (sha256 (base32
> "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
> > + (build-system trivial-build-system)
> > ...
> > + (substitute* (string-append %output "/bin/jpm")
> > + (("/usr/bin/env janet")
> > + (string-append #$janet "/bin/janet")))
>
> Is my understanding correct that you're updating the shebang line here?
> If so, would it be better to use the copy-build-system instead? If not,
> could you please elaborate? If copy-build-system does indeed turn out
> to be better suited, could you please send v3 of the patch?
>
> --
> Suhail
>
Attachment: file
O
O
Omar Bassam wrote on 30 Sep 10:12 +0200
[PATCH v3] adding jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
4e623d9571ff648ae1d1c6ffb8f9d73c421a5c10.1727683810.git.omar.bassam88@gmail.com
Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)

Toggle diff (58 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..7348ab5548 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,41 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-prefix-path
+ (lambda _
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") #$output))
+ (setenv "PREFIX" #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir) (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet" "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" = (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" = (,(string-append #$janet "/lib")))))))))
+ (inputs (list janet))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 093f2fb8722fafcc7c1555cd845289096849f4a2
--
2.45.2
S
S
Suhail Singh wrote on 1 Oct 02:06 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87plok7kkn.fsf@gmail.com
Omar, thank you for sending a revised patch. I have a few comments
relating to style and one unanswered question from our last exchange.

Toggle quote (2 lines)
> Subject: [bug#72925] [PATCH v3] adding jpm package

In v4, could you please update the commit message to conform to the
ChangeLog format as noted in
Please see
for additional details. If you're using magit,
`magit-generate-changelog' can help with this.

In your case the commit will probably look something like:
#+begin_quote
gnu: Add jpm.

* gnu/packages/lisp.scm (jpm): New variable.
#+end_quote

Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (12 lines)
> +(define-public jpm
> + (package
> + (name "jpm")
> + (version "1.1.0")
> + (source (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/janet-lang/jpm.git")
> + (commit (string-append "v" version))))
> + (file-name (git-file-name name version))
> + (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))

There are no build errors with this, however, it's not clear how to
verify that the runtime behaviour of jpm is as expected. After
installing janet and jpm in a guix profile, running a command such as:

#+begin_src sh
jpm install sh
#+end_src

Results in the following:

#+begin_example
$> jpm install sh
error: Read-only file system: /gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/.cache
in os/mkdir [src/core/os.c] on line 1981
in download-bundle [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 200, column 3
in bundle-install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 217, column 13
in resolve-bundle-name [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 118, column 20
in resolve-bundle [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 148, column 9
in bundle-install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 216, column 4
in install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/commands.janet] (tail call) on line 190, column 20
in run-main [boot.janet] on line 4432, column 16
in cli-main [boot.janet] on line 4613, column 17
#+end_example

Could you please share an example code snippet which can be used to
verify correctness of the installation?

Additionally, it seems that the jpm repository comes with a test
(./test/installtest.janet and ./testinstall). However, it doesn't seem
like we're running it during the build. Could you please share the
reasons why? If possible, we should enable and run these tests.

Toggle quote (13 lines)
> + (build-system copy-build-system)
> + (arguments
> + (list
> + #:phases #~(modify-phases %standard-phases
> + (add-after 'unpack 'fix-prefix-path
> + (lambda _
> + (substitute* "configs/linux_config.janet"
> + (("/usr/local") #$output))
> + (setenv "PREFIX" #$output)))

> + (replace 'install
> + (lambda _

V3 doesn't cleanly apply due to whitespace issues on this (^) line.
Please fix.

On a related note, in case you're not aware, please observe all the
steps listed in
Steps 3 and 4 recommend invoking guix lint and guix style which, unless
I'm mistaken, would've caught this issue.

--
Suhail
O
O
Omar Bassam wrote on 2 Oct 16:36 +0200
[PATCH v5] gnu: add jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
3b0b58bd01fc50abef6764fee5ec1d02dd15303d.1727879744.git.omar.bassam88@gmail.com
* gnu/packages/lisp.scm (jpm): New Variable

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)

Toggle diff (58 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..3f406c260a 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,41 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-prefix-path
+ (lambda _
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") #$output))
+ (setenv "PREFIX" #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir) (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet" "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" = (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" = (,(string-append #$janet "/lib")))))))))
+ (inputs (list janet))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 3d0668fe6667dabe71ee2840e75877f18399c1d9
--
2.45.2
O
O
Omar Bassam wrote on 2 Oct 16:50 +0200
[PATCH v6] gnu: add jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
3b0b58bd01fc50abef6764fee5ec1d02dd15303d.1727880584.git.omar.bassam88@gmail.com
* gnu/packages/lisp.scm (jpm): New Variable

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)

Toggle diff (58 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..3f406c260a 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,41 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256 (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-prefix-path
+ (lambda _
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local") #$output))
+ (setenv "PREFIX" #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir) (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet" "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" = (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" = (,(string-append #$janet "/lib")))))))))
+ (inputs (list janet))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 3d0668fe6667dabe71ee2840e75877f18399c1d9
--
2.45.2
O
O
Omar Bassam wrote on 2 Oct 16:51 +0200
[PATCH v7] gnu: add jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
39f8c254574fb6f02f67d7ed90ee6fc33d7fee7b.1727880688.git.omar.bassam88@gmail.com
* gnu/packages/lisp.scm (jpm): New Variable

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
---
gnu/packages/lisp.scm | 44 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

Toggle diff (66 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..f9ae0fe55a 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -917,6 +918,49 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-prefix-path
+ (lambda _
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list janet))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 3d0668fe6667dabe71ee2840e75877f18399c1d9
--
2.45.2
O
O
Omar Bassam wrote on 2 Oct 17:09 +0200
Re: [bug#72925] [PATCH v3] adding jpm package
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2raRiChOpksvFZOqrxRME7Tj2WKJiathvJyM-qCwGz3P-A@mail.gmail.com
Hi Suhail,
I just submitted a new patch (v7) applying your suggestions and running
guix lint and guix style.
regarding your questions. I'll try to answer them below:

On Tue, 1 Oct 2024 at 03:07, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (77 lines)
> Omar, thank you for sending a revised patch. I have a few comments
> relating to style and one unanswered question from our last exchange.
>
> > Subject: [bug#72925] [PATCH v3] adding jpm package
>
> In v4, could you please update the commit message to conform to the
> ChangeLog format as noted in
> <https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html>.
> Please see
> <https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
> >
> for additional details. If you're using magit,
> `magit-generate-changelog' can help with this.
>
> In your case the commit will probably look something like:
> #+begin_quote
> gnu: Add jpm.
>
> * gnu/packages/lisp.scm (jpm): New variable.
> #+end_quote
>
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > +(define-public jpm
> > + (package
> > + (name "jpm")
> > + (version "1.1.0")
> > + (source (origin
> > + (method git-fetch)
> > + (uri (git-reference
> > + (url "https://github.com/janet-lang/jpm.git")
> > + (commit (string-append "v" version))))
> > + (file-name (git-file-name name version))
> > + (sha256 (base32
> "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
>
> There are no build errors with this, however, it's not clear how to
> verify that the runtime behaviour of jpm is as expected. After
> installing janet and jpm in a guix profile, running a command such as:
>
> #+begin_src sh
> jpm install sh
> #+end_src
>
> Results in the following:
>
> #+begin_example
> $> jpm install sh
> error: Read-only file system:
> /gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/.cache
> in os/mkdir [src/core/os.c] on line 1981
> in download-bundle
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 200, column 3
> in bundle-install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 217, column 13
> in resolve-bundle-name
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 118, column 20
> in resolve-bundle
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 148, column 9
> in bundle-install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 216, column 4
> in install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/commands.janet]
> (tail call) on line 190, column 20
> in run-main [boot.janet] on line 4432, column 16
> in cli-main [boot.janet] on line 4613, column 17
> #+end_example
>
> Could you please share an example code snippet which can be used to
> verify correctness of the installation?
>
>
This is expected as the jpm install command is meant to install janet
packages globally which would be impure.
To install janet packages to your local project directory, you need to add
the "-l" flag as follows:
jpm install -l sh

Alternatively you can also set the JPM_TREE environment variable to install
to a custom directory that you have access to.

Maybe in the future we can add a "janet-build-system" that will allow us to
add janet packages to the guix repository.


Toggle quote (6 lines)
> Additionally, it seems that the jpm repository comes with a test
> (./test/installtest.janet and ./testinstall). However, it doesn't seem
> like we're running it during the build. Could you please share the
> reasons why? If possible, we should enable and run these tests.
>
>
These tests are not testing the installation of jpm, they are only testing
the "jpm install" command which will not work as I explained above.


Toggle quote (25 lines)
> > + (build-system copy-build-system)
> > + (arguments
> > + (list
> > + #:phases #~(modify-phases %standard-phases
> > + (add-after 'unpack 'fix-prefix-path
> > + (lambda _
> > + (substitute* "configs/linux_config.janet"
> > + (("/usr/local") #$output))
> > + (setenv "PREFIX" #$output)))
>
> > + (replace 'install
> > + (lambda _
>
> V3 doesn't cleanly apply due to whitespace issues on this (^) line.
> Please fix.
>
> On a related note, in case you're not aware, please observe all the
> steps listed in
> <https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html>.
> Steps 3 and 4 recommend invoking guix lint and guix style which, unless
> I'm mistaken, would've caught this issue.
>
> --
> Suhail
>
Attachment: file
S
S
Suhail Singh wrote on 2 Oct 20:21 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
8734lev012.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (3 lines)
> This is expected as the jpm install command is meant to install janet
> packages globally which would be impure.

It would help for this to be noted in some manner. Be it in the
description or as comments in the package description.

Toggle quote (4 lines)
> To install janet packages to your local project directory, you need to add
> the "-l" flag as follows:
> jpm install -l sh

Does this work for you (for jpm installed via guix)? If so, could you
please confirm the set of dependencies you have installed in the guix
profile for the above to work? If not, could you provide an example
invocation that I could test out which would allow me to install a janet
dependency in a local directory?

Toggle quote (3 lines)
> Maybe in the future we can add a "janet-build-system" that will allow us to
> add janet packages to the guix repository.

That would be helpful.

--
Suhail
J
J
jgart wrote on 2 Oct 21:04 +0200
ae3edde01e7d1e478302a2c2a6ba203f662f77a3@dismail.de
(un)related to this,

what do people think of having language specific guides for using `guix shell` with particular programming languages?

not unlike this Nix guide that shows how to use Python in a `nix shell` to develop on a flask application:


would be cool to document the expected workflow for a Guix user using jpm and guix to develop on janet software, for example.

we can continue my thought on #guix-devel didn't mean to distract ;()

wdyt,

jgart

Attachment: file
S
S
Suhail Singh wrote on 2 Oct 22:14 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
875xqanty2.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (9 lines)
>> > This is expected as the jpm install command is meant to install janet
>> > packages globally which would be impure.
>>
>> It would help for this to be noted in some manner. Be it in the
>> description or as comments in the package description.
>
> I don't think this needs to be said because all package managers installed
> via guix have this issue.

For me, someone familiar with Guix, but unfamiliar with Janet and JPM
defaults, it wasn't obvious that I needed to add "-l" to the invocation.

I don't believe such a message is necessary, but it would be helpful to
some (those individuals who aren't familiar with both JPM and Guix).

Toggle quote (4 lines)
> Also, there is no one way to solve this because jpm gives you the freedom
> to install packages on a user level
> or on a project only level.

The fact that JPM doesn't install packages at a user level by default
was not something I knew previously.

Toggle quote (13 lines)
>> > To install janet packages to your local project directory, you need to
>> add
>> > the "-l" flag as follows:
>> > jpm install -l sh
>>
>> Does this work for you (for jpm installed via guix)? If so, could you
>> please confirm the set of dependencies you have installed in the guix
>> profile for the above to work? If not, could you provide an example
>> invocation that I could test out which would allow me to install a janet
>> dependency in a local directory?
>
> Do you still get the same error?

No, a different one.

Toggle quote (3 lines)
> Yes, this does work for me without any other dependencies. I am using guix
> on ubuntu with guix shell.

I am running guix-shell (--pure) with the following dependencies
installed:
- janet
- gcc-toolchain gcc-toolchain:static
- openssl
- git
- jpm
- bash coreutils
- curl nss-certs

With the above, when running "jpm --local install sh" I observe the
following error:

#+begin_example
error: ( "cc"
"-std=c99"
"-I/gnu/store/rdlvs1p09brkk961lj3vncifb4xlsmm5-janet-1.36.0/include/janet"
"-I/tmp/review-72925/jpm_tree/lib"
"-O2"
"-o"
"build/_jmod_posix_spawn.so"
"build/posix-spawn.o"
"-shared"
"-pthread"): No such file or directory
error: build fail
in pdag [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/dagbuild.janet] (tail call) on line 79, column 23
in with-dyns [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 236, column 9
in defer [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 221, column 5
in bundle-install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 219, column 3
in with-dyns [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 234, column 13
in defer [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 221, column 5
in bundle-install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet] on line 219, column 3
in install [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/commands.janet] (tail call) on line 190, column 20
in run-main [boot.janet] on line 4432, column 16
in cli-main [boot.janet] on line 4613, column 17
#+end_example

When running "jpm --cc=gcc --local install sh" I get the same error.

I was finally able to get it to succeed by having cc symlink to gcc and
adding the directory containing the symlink to PATH. So I believe that
the package definition you've submitted is correct. However, I'm
wondering what (if anything) needs to be done about the issue I
encountered.

Specifically, it's unclear why passing "-cc=gcc" didn't work (nor did
setting "CC=gcc", but perhaps JPM ignores the latter?). Is this an
upstream bug? Were my expectations misplaced? Should the JPM package
in Guix provide "cc" as well?

--
Suhail
J
J
jgart wrote on 2 Oct 22:27 +0200
0a8758f3974bdfdb2bd19a87de60c0d65fa824b4@dismail.de
Toggle quote (3 lines)
>
> upstream bug? Were my expectations misplaced?
>
Suhail,

These are all very good points.

Excuse the brevity as i am going on a hiking trip and need to prepare now,

jgart

PS. I'll be away till the 8th.

Attachment: file
J
J
jgart wrote on 2 Oct 22:33 +0200
b6981a8d8531cff6d7fa78a380477f7d42ff041c@dismail.de
Toggle quote (10 lines)
>
> This is where jgart suggestion would be really helpful. I am personally working on a project
> https://lisp-spectrum.org/ where I try to document all the struggles that I had with the Lisp ecosystem
> and try to make it more accessible to new users. (Any contributions are welcomed of course).
>  
>
> >
> >
> >
>
That's a cool site. Let me get back to you on it once I am back from my hiking trip.

Thanks for sharing. I usually hang out at #whereiseveryone on irc.libera.chat.

Feel free to join me there or send me a personal email or I will once I am back on the 8th.

all best,

jgart

Attachment: file
S
S
Suhail Singh wrote on 2 Oct 23:39 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87cyki9obi.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (18 lines)
>> When running "jpm --cc=gcc --local install sh" I get the same error.
>>
>> I was finally able to get it to succeed by having cc symlink to gcc and
>> adding the directory containing the symlink to PATH. So I believe that
>> the package definition you've submitted is correct. However, I'm
>> wondering what (if anything) needs to be done about the issue I
>> encountered.
>>
>> Specifically, it's unclear why passing "-cc=gcc" didn't work (nor did
>> setting "CC=gcc", but perhaps JPM ignores the latter?). Is this an
>> upstream bug? Were my expectations misplaced? Should the JPM package
>> in Guix provide "cc" as well?
>>
>
> No, this is not really a Janet or JPM issue but rather the fact that
> you are overriding the gcc compiler with a symlinked binary instead of
> the absolute path.

I don't understand.

All four variants below fail in exactly the same way:

#+begin_src sh
jpm --cc=gcc -l install sh
#+end_src

#+begin_src sh
jpm --cc=/home/user/.guix-profile/bin/gcc -l install sh
#+end_src

#+begin_src sh
jpm --cc=/gnu/store/x2kv3zw2k7ql211m5kvb6yw401gab0x9-gcc-toolchain-14.2.0/bin/gcc -l install sh
#+end_src

#+begin_src sh
jpm --cc=/gnu/store/lq9y7sd4mvffs4hqp3hkr9fnd384pnkj-gcc-14.2.0/bin/gcc -l install sh
#+end_src

Note that the last variant uses an absolute path.

Either I'm not using the "--cc" option correctly. Or for some
dependency of "sh" (specifically, posix-spawn) the compiler has been
hardcoded to "cc" and it's not picking up the option being passed to
jpm.

Further, if the above work for you in a "--pure" guix shell (where it
doesn't for me), that's surprising.

It is _only_ when I provide a fake "cc" (which is simply a symlink to
gcc) that things work.

--
Suhail
S
S
Suhail Singh wrote on 3 Oct 00:07 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
878qv69n0o.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (2 lines)
> I don't think this should be related to this patch.

As I mentioned previously, I believe your packaging of "jpm" is
correctly done. I was hoping to get some understanding as to why it
doesn't work as expected, however.

Toggle quote (4 lines)
> Also, if you are running a guix shell with --pure flag, try adding
> coreutils to your shell because jpm calls the "cp" command when building
> libraries.

As noted previously, coreutils is included as a dependency in the
profile.

Toggle quote (3 lines)
> I tried with "jpm install -l spork" and with "jpm install -l sh" and it
> works fine.

Both fail for me.

Is my understanding correct that you're not using a "--pure" shell and,
thus, have "cc" provided by the system? Could you please share the
output of "type cc" in the environment where you ran the above jpm
commands?

Toggle quote (2 lines)
> I believe the --cc flag is meant to be used for the jpm build command.

Even though it's listed under "Global options" for jpm? Interesting.
If true, that would certainly explain why passing --cc didn't seem to
help.

--
Suhail
S
S
Suhail Singh wrote on 3 Oct 03:40 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
874j5u7yme.fsf@gmail.com
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (5 lines)
>> I don't think this should be related to this patch.
>
> As I mentioned previously, I believe your packaging of "jpm" is
> correctly done.

After having taken a look at the source of JPM, I believe I was
previously mistaken. I don't believe the JPM packaging is correct. And
I do believe that the issue I was observing is related to the patch.

Specifically, in the file "configs/linux_config.janet", among other
things, the below are set

#+begin_src janet
:c++ "c++"
:c++-link "c++"
:cc "cc"
:cc-link "cc"
#+end_src

Since Guix, as far as I know, doesn't have packages that provide c++ nor
cc, I believe the above need to be patched to refer to gcc and g++
respectively.

Further, I believe JPM should have a few propagated inputs:
- gcc-toolchain
- curl
- git
- nss-certs.

Please address the above two in v8 if you agree. If not, please help me
understand where I may have erred in the analysis above.

--
Suhail
O
O
Omar Bassam wrote on 2 Oct 21:12 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2ra=o=Ho7Nny8cX-rmcVBau8pD+Qb0_ZA+=Fwv5u7n_utw@mail.gmail.com
Hi Suhail,

Sorry if some of my instructions were not clear before. I'll try to explain
in more detail.

On Wed, 2 Oct 2024 at 21:21, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (9 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > This is expected as the jpm install command is meant to install janet
> > packages globally which would be impure.
>
> It would help for this to be noted in some manner. Be it in the
> description or as comments in the package description.
>

I don't think this needs to be said because all package managers installed
via guix have this issue.
This is a common Nix/Guix issue that I struggled a lot to understand at the
beginning.
Also, there is no one way to solve this because jpm gives you the freedom
to install packages on a user level
or on a project only level.


Toggle quote (12 lines)
> > To install janet packages to your local project directory, you need to
> add
> > the "-l" flag as follows:
> > jpm install -l sh
>
> Does this work for you (for jpm installed via guix)? If so, could you
> please confirm the set of dependencies you have installed in the guix
> profile for the above to work? If not, could you provide an example
> invocation that I could test out which would allow me to install a janet
> dependency in a local directory?
>

Do you still get the same error?
Yes, this does work for me without any other dependencies. I am using guix
on ubuntu with guix shell.
It should create a "jpm_tree" folder in the directory where you invoked the
command from.
Alternatively you can set the "JANET_TREE" environment variable before
invoking the command. For example:
JANET_TREE=~/.jpm jpm install sh

Also, note that janet is a lisp that compiles to C. So, if the library you
are trying to install has other dependencies,
you'll need to have those available in your profile/shell.



Toggle quote (6 lines)
> > Maybe in the future we can add a "janet-build-system" that will allow us
> to
> > add janet packages to the guix repository.
>
> That would be helpful.
>
Yes, indeed. I don't have much experience about that yet. But I plan to do
so in the future.

Toggle quote (3 lines)
> --
> Suhail
>
Attachment: file
O
O
Omar Bassam wrote on 2 Oct 22:27 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rbRNf2keckWZztc4VkUFQt2WBb+e2oYLdZsffaUOcchZw@mail.gmail.com
On Wed, 2 Oct 2024 at 23:14, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (19 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> >> > This is expected as the jpm install command is meant to install janet
> >> > packages globally which would be impure.
> >>
> >> It would help for this to be noted in some manner. Be it in the
> >> description or as comments in the package description.
> >
> > I don't think this needs to be said because all package managers
> installed
> > via guix have this issue.
>
> For me, someone familiar with Guix, but unfamiliar with Janet and JPM
> defaults, it wasn't obvious that I needed to add "-l" to the invocation.
>
> I don't believe such a message is necessary, but it would be helpful to
> some (those individuals who aren't familiar with both JPM and Guix).
>

This is where jgart suggestion would be really helpful. I am personally
working on a project
https://lisp-spectrum.org/where I try to document all the struggles that I
had with the Lisp ecosystem
and try to make it more accessible to new users. (Any contributions are
welcomed of course).


Toggle quote (95 lines)
>
> > Also, there is no one way to solve this because jpm gives you the freedom
> > to install packages on a user level
> > or on a project only level.
>
> The fact that JPM doesn't install packages at a user level by default
> was not something I knew previously.
>
> >> > To install janet packages to your local project directory, you need to
> >> add
> >> > the "-l" flag as follows:
> >> > jpm install -l sh
> >>
> >> Does this work for you (for jpm installed via guix)? If so, could you
> >> please confirm the set of dependencies you have installed in the guix
> >> profile for the above to work? If not, could you provide an example
> >> invocation that I could test out which would allow me to install a janet
> >> dependency in a local directory?
> >
> > Do you still get the same error?
>
> No, a different one.
>
> > Yes, this does work for me without any other dependencies. I am using
> guix
> > on ubuntu with guix shell.
>
> I am running guix-shell (--pure) with the following dependencies
> installed:
> - janet
> - gcc-toolchain gcc-toolchain:static
> - openssl
> - git
> - jpm
> - bash coreutils
> - curl nss-certs
>
> With the above, when running "jpm --local install sh" I observe the
> following error:
>
> #+begin_example
> error: ( "cc"
> "-std=c99"
>
> "-I/gnu/store/rdlvs1p09brkk961lj3vncifb4xlsmm5-janet-1.36.0/include/janet"
> "-I/tmp/review-72925/jpm_tree/lib"
> "-O2"
> "-o"
> "build/_jmod_posix_spawn.so"
> "build/posix-spawn.o"
> "-shared"
> "-pthread"): No such file or directory
> error: build fail
> in pdag
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/dagbuild.janet]
> (tail call) on line 79, column 23
> in with-dyns
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 236, column 9
> in defer
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 221, column 5
> in bundle-install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 219, column 3
> in with-dyns
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 234, column 13
> in defer
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 221, column 5
> in bundle-install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/pm.janet]
> on line 219, column 3
> in install
> [/gnu/store/ffmis4y6rld42biqx5lq4nvsjp0bqiq6-jpm-1.1.0/lib/janet/jpm/commands.janet]
> (tail call) on line 190, column 20
> in run-main [boot.janet] on line 4432, column 16
> in cli-main [boot.janet] on line 4613, column 17
> #+end_example
>
> When running "jpm --cc=gcc --local install sh" I get the same error.
>
> I was finally able to get it to succeed by having cc symlink to gcc and
> adding the directory containing the symlink to PATH. So I believe that
> the package definition you've submitted is correct. However, I'm
> wondering what (if anything) needs to be done about the issue I
> encountered.
>
> Specifically, it's unclear why passing "-cc=gcc" didn't work (nor did
> setting "CC=gcc", but perhaps JPM ignores the latter?). Is this an
> upstream bug? Were my expectations misplaced? Should the JPM package
> in Guix provide "cc" as well?
>

No, this is not really a Janet or JPM issue but rather the fact that you
are overriding the gcc compiler with a symlinked binary
instead of the absolute path. I faced this issue as well with
LD_LIBRARY_PATH where you have to use "readlink" to point it
to the absolute path of the "lib" folder in your guix profile.


Toggle quote (3 lines)
> --
> Suhail
>
Attachment: file
O
O
Omar Bassam wrote on 2 Oct 23:52 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rawx+Dwrs5pGX+V++JkeOpK9drees-9NFCPkYNH3TQKpA@mail.gmail.com
On Thu, 3 Oct 2024 at 00:39, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (60 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> >> When running "jpm --cc=gcc --local install sh" I get the same error.
> >>
> >> I was finally able to get it to succeed by having cc symlink to gcc and
> >> adding the directory containing the symlink to PATH. So I believe that
> >> the package definition you've submitted is correct. However, I'm
> >> wondering what (if anything) needs to be done about the issue I
> >> encountered.
> >>
> >> Specifically, it's unclear why passing "-cc=gcc" didn't work (nor did
> >> setting "CC=gcc", but perhaps JPM ignores the latter?). Is this an
> >> upstream bug? Were my expectations misplaced? Should the JPM package
> >> in Guix provide "cc" as well?
> >>
> >
> > No, this is not really a Janet or JPM issue but rather the fact that
> > you are overriding the gcc compiler with a symlinked binary instead of
> > the absolute path.
>
> I don't understand.
>
> All four variants below fail in exactly the same way:
>
> #+begin_src sh
> jpm --cc=gcc -l install sh
> #+end_src
>
> #+begin_src sh
> jpm --cc=/home/user/.guix-profile/bin/gcc -l install sh
> #+end_src
>
> #+begin_src sh
> jpm
> --cc=/gnu/store/x2kv3zw2k7ql211m5kvb6yw401gab0x9-gcc-toolchain-14.2.0/bin/gcc
> -l install sh
> #+end_src
>
> #+begin_src sh
> jpm --cc=/gnu/store/lq9y7sd4mvffs4hqp3hkr9fnd384pnkj-gcc-14.2.0/bin/gcc
> -l install sh
> #+end_src
>
> Note that the last variant uses an absolute path.
>
> Either I'm not using the "--cc" option correctly. Or for some
> dependency of "sh" (specifically, posix-spawn) the compiler has been
> hardcoded to "cc" and it's not picking up the option being passed to
> jpm.
>
> Further, if the above work for you in a "--pure" guix shell (where it
> doesn't for me), that's surprising.
>
> It is _only_ when I provide a fake "cc" (which is simply a symlink to
> gcc) that things work.
>
> --
> Suhail
>

I believe this is a library specific thing. I don't think this should be
related to this patch.
Also, if you are running a guix shell with --pure flag, try adding
coreutils to your shell because jpm calls the "cp" command when building
libraries.
I tried with "jpm install -l spork" and with "jpm install -l sh" and it
works fine. I believe the --cc flag is meant to be used for the jpm build
command.
Attachment: file
O
O
Omar Bassam wrote on 3 Oct 09:14 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rZk1GVda4kE7qKLKbqB=Dv_gjZSnxt4hU68w_j4aAq-8w@mail.gmail.com
Hi Suhail,
I just have some questions before submitting v8 if you don't mind. just to
make sure I understand correctly.

On Thu, 3 Oct 2024 at 04:40, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (26 lines)
> Suhail Singh <suhailsingh247@gmail.com> writes:
>
> >> I don't think this should be related to this patch.
> >
> > As I mentioned previously, I believe your packaging of "jpm" is
> > correctly done.
>
> After having taken a look at the source of JPM, I believe I was
> previously mistaken. I don't believe the JPM packaging is correct. And
> I do believe that the issue I was observing is related to the patch.
>
> Specifically, in the file "configs/linux_config.janet", among other
> things, the below are set
>
> #+begin_src janet
> :c++ "c++"
> :c++-link "c++"
> :cc "cc"
> :cc-link "cc"
> #+end_src
>
> Since Guix, as far as I know, doesn't have packages that provide c++ nor
> cc, I believe the above need to be patched to refer to gcc and g++
> respectively.
>
> So we need to substitute the above "c++" and "cc" in the
"configs/linux_config.janet" to point to the absolute path for the gcc and
g++ packages?
Should we also replace other commands that are hard-coded like "cp" and
"chown" from coreutils the same way I did in my first initial patch?

Further, I believe JPM should have a few propagated inputs:
Toggle quote (6 lines)
> - gcc-toolchain
> - curl
> - git
> - nss-certs.
>
> I understand why we need gcc-toolchain. But why do we need curl, git and
nss-certs?

Please address the above two in v8 if you agree. If not, please help me
Toggle quote (6 lines)
> understand where I may have erred in the analysis above.
>
> --
> Suhail
>

Thanks,
Omar
Attachment: file
S
S
Suhail Singh wrote on 3 Oct 15:40 +0200
Re: bug#72925: Adding JPM package for Janet
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87jzep2tlb.fsf_-_@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (3 lines)
> I just have some questions before submitting v8 if you don't mind. just to
> make sure I understand correctly.

Questions are always welcome :)

Toggle quote (18 lines)
>> Specifically, in the file "configs/linux_config.janet", among other
>> things, the below are set
>>
>> #+begin_src janet
>> :c++ "c++"
>> :c++-link "c++"
>> :cc "cc"
>> :cc-link "cc"
>> #+end_src
>>
>> Since Guix, as far as I know, doesn't have packages that provide c++ nor
>> cc, I believe the above need to be patched to refer to gcc and g++
>> respectively.
>>
>> So we need to substitute the above "c++" and "cc" in the
> "configs/linux_config.janet" to point to the absolute path for the gcc and
> g++ packages?

I believe there are multiple ways to make this work. I haven't tested
this, so take my opinions as speculative.

If we replace "cc" and "c++" with the _absolute path_ for "gcc" and
"g++" respectively from the Guix store, then I don't think we need to
specify gcc-toolchain as a propagated input. Upon reflecting on this,
this is probably the better approach.

If, however, we replace "cc" and "c++" with the _strings_ "gcc" and
"g++", then I believe we may need to specify gcc-toolchain in the
propagated inputs. IIUC, in this case we would replace the command that
JPM invokes when building. By additionally having gcc-toolchain in the
propagated inputs we'll ensure that they're available in the PATH.

Toggle quote (3 lines)
> Should we also replace other commands that are hard-coded like "cp" and
> "chown" from coreutils the same way I did in my first initial patch?

I don't believe this is necessary. There's a question regd. whether or
not coreutils needs to be added to the propagated inputs, however. I
don't have a definitive answer, but the way to test it would be to run
it in a pure container and see if things work without having to
explicitly specify coreutils. If you're unable to test it, let me know
when you send v8 and I can test it on your behalf.

For reference, I use something like the below:
#+begin_src sh
guix shell --pure -CPWN \
-E '.*GTK.*|.*XDG.*|.*DISPLAY.*|TERM|INSIDE_EMACS' \
-p /path/to/profile
#+end_src

Toggle quote (9 lines)
> Further, I believe JPM should have a few propagated inputs:
>> - gcc-toolchain
>> - curl
>> - git
>> - nss-certs.
>>
>> I understand why we need gcc-toolchain. But why do we need curl, git and
> nss-certs?

linux_config.janet also specifies:

#+begin_src janet
...
:curlpath "curl"
...
:gitpath "git"
...
#+end_src

Whether Guix packaging picks these up automatically or not, I haven't
tested, but it seems for common usage of JPM these dependencies ought to
be available. Similar to the case of "gcc" and "g++", it might be
better to replace these with references to the respective binaries in
the Guix store instead (as opposed to propagating them as I had
previously suggested).

Regarding nss-certs, it provides certificates for Certification
Authorities which, IIUC, would be relevant for HTTPS URLs (e.g. fetching
dependencies over git+https).

To summarize, here's what I believe is needed. Add nss-certs to the
propagated inputs, and for the below replace their occurrence in
linux_config.janet with references to binaries in the store:
- cc -> absolute path of gcc
- c++ -> absolute path of g++
- curl -> absolute path of curl
- git -> absolute path of git

--
Suhail
O
O
Omar Bassam wrote on 3 Oct 21:45 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rYx_8eBqqp6izthWJa9XtSy9Pgb2zFLcQASWVZLw3rntw@mail.gmail.com
Hi Suhail,
I really need some help here.
I am having trouble using gcc-toolchain because when I add the (gnu
packages commencement) modules to the lisp.scm file I get a lot of errors
that I don't understand.
I was able to create a local manifest file with the definition of my
package and made the substitutions you suggested and added the propagated
input and it worked fine.
The issue that I'm having now is to include it in the lisp.scm file.
Can you tell what's the right use-module form I need to use?

On Thu, 3 Oct 2024 at 16:40, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (99 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > I just have some questions before submitting v8 if you don't mind. just
> to
> > make sure I understand correctly.
>
> Questions are always welcome :)
>
> >> Specifically, in the file "configs/linux_config.janet", among other
> >> things, the below are set
> >>
> >> #+begin_src janet
> >> :c++ "c++"
> >> :c++-link "c++"
> >> :cc "cc"
> >> :cc-link "cc"
> >> #+end_src
> >>
> >> Since Guix, as far as I know, doesn't have packages that provide c++ nor
> >> cc, I believe the above need to be patched to refer to gcc and g++
> >> respectively.
> >>
> >> So we need to substitute the above "c++" and "cc" in the
> > "configs/linux_config.janet" to point to the absolute path for the gcc
> and
> > g++ packages?
>
> I believe there are multiple ways to make this work. I haven't tested
> this, so take my opinions as speculative.
>
> If we replace "cc" and "c++" with the _absolute path_ for "gcc" and
> "g++" respectively from the Guix store, then I don't think we need to
> specify gcc-toolchain as a propagated input. Upon reflecting on this,
> this is probably the better approach.
>
> If, however, we replace "cc" and "c++" with the _strings_ "gcc" and
> "g++", then I believe we may need to specify gcc-toolchain in the
> propagated inputs. IIUC, in this case we would replace the command that
> JPM invokes when building. By additionally having gcc-toolchain in the
> propagated inputs we'll ensure that they're available in the PATH.
>
> > Should we also replace other commands that are hard-coded like "cp" and
> > "chown" from coreutils the same way I did in my first initial patch?
>
> I don't believe this is necessary. There's a question regd. whether or
> not coreutils needs to be added to the propagated inputs, however. I
> don't have a definitive answer, but the way to test it would be to run
> it in a pure container and see if things work without having to
> explicitly specify coreutils. If you're unable to test it, let me know
> when you send v8 and I can test it on your behalf.
>
> For reference, I use something like the below:
> #+begin_src sh
> guix shell --pure -CPWN \
> -E '.*GTK.*|.*XDG.*|.*DISPLAY.*|TERM|INSIDE_EMACS' \
> -p /path/to/profile
> #+end_src
>
> > Further, I believe JPM should have a few propagated inputs:
> >> - gcc-toolchain
> >> - curl
> >> - git
> >> - nss-certs.
> >>
> >> I understand why we need gcc-toolchain. But why do we need curl, git and
> > nss-certs?
>
> linux_config.janet also specifies:
>
> #+begin_src janet
> ...
> :curlpath "curl"
> ...
> :gitpath "git"
> ...
> #+end_src
>
> Whether Guix packaging picks these up automatically or not, I haven't
> tested, but it seems for common usage of JPM these dependencies ought to
> be available. Similar to the case of "gcc" and "g++", it might be
> better to replace these with references to the respective binaries in
> the Guix store instead (as opposed to propagating them as I had
> previously suggested).
>
> Regarding nss-certs, it provides certificates for Certification
> Authorities which, IIUC, would be relevant for HTTPS URLs (e.g. fetching
> dependencies over git+https).
>
> To summarize, here's what I believe is needed. Add nss-certs to the
> propagated inputs, and for the below replace their occurrence in
> linux_config.janet with references to binaries in the store:
> - cc -> absolute path of gcc
> - c++ -> absolute path of g++
> - curl -> absolute path of curl
> - git -> absolute path of git
>
> --
> Suhail
>
Attachment: file
O
O
Omar Bassam wrote on 4 Oct 00:04 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rYOtAgU3YEGBUSUzR_h_4vCnUdB1a9EGbhShzEY7J-2Yg@mail.gmail.com
It's OK I figured it out now. I'll be posting the patch soon.

On Thu, 3 Oct 2024 at 22:45, Omar Bassam <omar.bassam88@gmail.com> wrote:

Toggle quote (116 lines)
> Hi Suhail,
> I really need some help here.
> I am having trouble using gcc-toolchain because when I add the (gnu
> packages commencement) modules to the lisp.scm file I get a lot of errors
> that I don't understand.
> I was able to create a local manifest file with the definition of my
> package and made the substitutions you suggested and added the propagated
> input and it worked fine.
> The issue that I'm having now is to include it in the lisp.scm file.
> Can you tell what's the right use-module form I need to use?
>
> On Thu, 3 Oct 2024 at 16:40, Suhail Singh <suhailsingh247@gmail.com>
> wrote:
>
>> Omar Bassam <omar.bassam88@gmail.com> writes:
>>
>> > I just have some questions before submitting v8 if you don't mind. just
>> to
>> > make sure I understand correctly.
>>
>> Questions are always welcome :)
>>
>> >> Specifically, in the file "configs/linux_config.janet", among other
>> >> things, the below are set
>> >>
>> >> #+begin_src janet
>> >> :c++ "c++"
>> >> :c++-link "c++"
>> >> :cc "cc"
>> >> :cc-link "cc"
>> >> #+end_src
>> >>
>> >> Since Guix, as far as I know, doesn't have packages that provide c++
>> nor
>> >> cc, I believe the above need to be patched to refer to gcc and g++
>> >> respectively.
>> >>
>> >> So we need to substitute the above "c++" and "cc" in the
>> > "configs/linux_config.janet" to point to the absolute path for the gcc
>> and
>> > g++ packages?
>>
>> I believe there are multiple ways to make this work. I haven't tested
>> this, so take my opinions as speculative.
>>
>> If we replace "cc" and "c++" with the _absolute path_ for "gcc" and
>> "g++" respectively from the Guix store, then I don't think we need to
>> specify gcc-toolchain as a propagated input. Upon reflecting on this,
>> this is probably the better approach.
>>
>> If, however, we replace "cc" and "c++" with the _strings_ "gcc" and
>> "g++", then I believe we may need to specify gcc-toolchain in the
>> propagated inputs. IIUC, in this case we would replace the command that
>> JPM invokes when building. By additionally having gcc-toolchain in the
>> propagated inputs we'll ensure that they're available in the PATH.
>>
>> > Should we also replace other commands that are hard-coded like "cp" and
>> > "chown" from coreutils the same way I did in my first initial patch?
>>
>> I don't believe this is necessary. There's a question regd. whether or
>> not coreutils needs to be added to the propagated inputs, however. I
>> don't have a definitive answer, but the way to test it would be to run
>> it in a pure container and see if things work without having to
>> explicitly specify coreutils. If you're unable to test it, let me know
>> when you send v8 and I can test it on your behalf.
>>
>> For reference, I use something like the below:
>> #+begin_src sh
>> guix shell --pure -CPWN \
>> -E '.*GTK.*|.*XDG.*|.*DISPLAY.*|TERM|INSIDE_EMACS' \
>> -p /path/to/profile
>> #+end_src
>>
>> > Further, I believe JPM should have a few propagated inputs:
>> >> - gcc-toolchain
>> >> - curl
>> >> - git
>> >> - nss-certs.
>> >>
>> >> I understand why we need gcc-toolchain. But why do we need curl, git
>> and
>> > nss-certs?
>>
>> linux_config.janet also specifies:
>>
>> #+begin_src janet
>> ...
>> :curlpath "curl"
>> ...
>> :gitpath "git"
>> ...
>> #+end_src
>>
>> Whether Guix packaging picks these up automatically or not, I haven't
>> tested, but it seems for common usage of JPM these dependencies ought to
>> be available. Similar to the case of "gcc" and "g++", it might be
>> better to replace these with references to the respective binaries in
>> the Guix store instead (as opposed to propagating them as I had
>> previously suggested).
>>
>> Regarding nss-certs, it provides certificates for Certification
>> Authorities which, IIUC, would be relevant for HTTPS URLs (e.g. fetching
>> dependencies over git+https).
>>
>> To summarize, here's what I believe is needed. Add nss-certs to the
>> propagated inputs, and for the below replace their occurrence in
>> linux_config.janet with references to binaries in the store:
>> - cc -> absolute path of gcc
>> - c++ -> absolute path of g++
>> - curl -> absolute path of curl
>> - git -> absolute path of git
>>
>> --
>> Suhail
>>
>
Attachment: file
O
O
Omar Bassam wrote on 4 Oct 17:57 +0200
[PATCH v8] gnu: add jpm package
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
8223c6391ac0b6a7d0aba42d32eb037c2deef26d.1728055031.git.omar.bassam88@gmail.com
* gnu/packages/lisp.scm (jpm): New Variable

Change-Id: I92cf244ab23062ae3448099506d1b068394d7094
---
gnu/packages/lisp.scm | 72 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)

Toggle diff (101 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..ee9913f14e 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -70,6 +71,7 @@ (define-module (gnu packages lisp)
#:use-module (gnu packages bdw-gc)
#:use-module (gnu packages boost)
#:use-module (gnu packages check)
+ #:use-module (gnu packages certs)
#:use-module (gnu packages compression)
#:use-module (gnu packages crypto)
#:use-module (gnu packages curl)
@@ -917,6 +919,76 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm.git")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ (assoc-ref inputs "gcc-toolchain")
+ "/bin/gcc" "\""))
+ (("\"c++\"")
+ (string-append "\""
+ (assoc-ref inputs "gcc-toolchain")
+ "/bin/g++" "\""))
+ (("\"git\"")
+ (string-append "\""
+ #$git "/bin/git" "\""))
+ (("\"curl\"")
+ (string-append "\""
+ #$curl "/bin/curl" "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append #$coreutils "/bin/cp")))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal janet))
+ (propagated-inputs (list janet
+ coreutils
+ git
+ curl
+ nss-certs
+ ;; Lazily resolve the gcc-toolchain to avoid
+ ;; a circular dependency.
+ (module-ref (resolve-interface '(gnu packages
+ commencement))
+ 'gcc-toolchain)))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description "JPM is the Janet Project Manager tool. It is for automating
+builds and downloading dependencies of Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: ebb715aabfc4e59ed14b964ac7fdd2a9f9f44526
--
2.45.2
O
O
Omar Bassam wrote on 4 Oct 18:00 +0200
Re: bug#72925: Adding JPM package for Janet
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
CAGSr2rYi3=8U6HO6goqhzdZPEB356odUgCDzxnJAQeUa9O3KCQ@mail.gmail.com
Hi Suhail,

I just submitted a new path v8. I tested in a pure container shell and it
worked for me for the following commands:

- "jpm install -l sh"
- "jpm install -l spork"
- "jpm build" : for a basic hello world project

Can you please have another look and let me know if you have any comments

Thanks,
*Omar*

On Fri, 4 Oct 2024 at 01:04, Omar Bassam <omar.bassam88@gmail.com> wrote:

Toggle quote (120 lines)
> It's OK I figured it out now. I'll be posting the patch soon.
>
> On Thu, 3 Oct 2024 at 22:45, Omar Bassam <omar.bassam88@gmail.com> wrote:
>
>> Hi Suhail,
>> I really need some help here.
>> I am having trouble using gcc-toolchain because when I add the (gnu
>> packages commencement) modules to the lisp.scm file I get a lot of errors
>> that I don't understand.
>> I was able to create a local manifest file with the definition of my
>> package and made the substitutions you suggested and added the propagated
>> input and it worked fine.
>> The issue that I'm having now is to include it in the lisp.scm file.
>> Can you tell what's the right use-module form I need to use?
>>
>> On Thu, 3 Oct 2024 at 16:40, Suhail Singh <suhailsingh247@gmail.com>
>> wrote:
>>
>>> Omar Bassam <omar.bassam88@gmail.com> writes:
>>>
>>> > I just have some questions before submitting v8 if you don't mind.
>>> just to
>>> > make sure I understand correctly.
>>>
>>> Questions are always welcome :)
>>>
>>> >> Specifically, in the file "configs/linux_config.janet", among other
>>> >> things, the below are set
>>> >>
>>> >> #+begin_src janet
>>> >> :c++ "c++"
>>> >> :c++-link "c++"
>>> >> :cc "cc"
>>> >> :cc-link "cc"
>>> >> #+end_src
>>> >>
>>> >> Since Guix, as far as I know, doesn't have packages that provide c++
>>> nor
>>> >> cc, I believe the above need to be patched to refer to gcc and g++
>>> >> respectively.
>>> >>
>>> >> So we need to substitute the above "c++" and "cc" in the
>>> > "configs/linux_config.janet" to point to the absolute path for the gcc
>>> and
>>> > g++ packages?
>>>
>>> I believe there are multiple ways to make this work. I haven't tested
>>> this, so take my opinions as speculative.
>>>
>>> If we replace "cc" and "c++" with the _absolute path_ for "gcc" and
>>> "g++" respectively from the Guix store, then I don't think we need to
>>> specify gcc-toolchain as a propagated input. Upon reflecting on this,
>>> this is probably the better approach.
>>>
>>> If, however, we replace "cc" and "c++" with the _strings_ "gcc" and
>>> "g++", then I believe we may need to specify gcc-toolchain in the
>>> propagated inputs. IIUC, in this case we would replace the command that
>>> JPM invokes when building. By additionally having gcc-toolchain in the
>>> propagated inputs we'll ensure that they're available in the PATH.
>>>
>>> > Should we also replace other commands that are hard-coded like "cp" and
>>> > "chown" from coreutils the same way I did in my first initial patch?
>>>
>>> I don't believe this is necessary. There's a question regd. whether or
>>> not coreutils needs to be added to the propagated inputs, however. I
>>> don't have a definitive answer, but the way to test it would be to run
>>> it in a pure container and see if things work without having to
>>> explicitly specify coreutils. If you're unable to test it, let me know
>>> when you send v8 and I can test it on your behalf.
>>>
>>> For reference, I use something like the below:
>>> #+begin_src sh
>>> guix shell --pure -CPWN \
>>> -E '.*GTK.*|.*XDG.*|.*DISPLAY.*|TERM|INSIDE_EMACS' \
>>> -p /path/to/profile
>>> #+end_src
>>>
>>> > Further, I believe JPM should have a few propagated inputs:
>>> >> - gcc-toolchain
>>> >> - curl
>>> >> - git
>>> >> - nss-certs.
>>> >>
>>> >> I understand why we need gcc-toolchain. But why do we need curl, git
>>> and
>>> > nss-certs?
>>>
>>> linux_config.janet also specifies:
>>>
>>> #+begin_src janet
>>> ...
>>> :curlpath "curl"
>>> ...
>>> :gitpath "git"
>>> ...
>>> #+end_src
>>>
>>> Whether Guix packaging picks these up automatically or not, I haven't
>>> tested, but it seems for common usage of JPM these dependencies ought to
>>> be available. Similar to the case of "gcc" and "g++", it might be
>>> better to replace these with references to the respective binaries in
>>> the Guix store instead (as opposed to propagating them as I had
>>> previously suggested).
>>>
>>> Regarding nss-certs, it provides certificates for Certification
>>> Authorities which, IIUC, would be relevant for HTTPS URLs (e.g. fetching
>>> dependencies over git+https).
>>>
>>> To summarize, here's what I believe is needed. Add nss-certs to the
>>> propagated inputs, and for the below replace their occurrence in
>>> linux_config.janet with references to binaries in the store:
>>> - cc -> absolute path of gcc
>>> - c++ -> absolute path of g++
>>> - curl -> absolute path of curl
>>> - git -> absolute path of git
>>>
>>> --
>>> Suhail
>>>
>>
Attachment: file
S
S
Suhail Singh wrote on 5 Oct 05:11 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87jzenkzvh.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (2 lines)
> I just submitted a new path v8. I tested in a pure container shell

Thank you.

Toggle quote (2 lines)
> Can you please have another look and let me know if you have any comments

I was unable to cleanly apply v8 on master. Additionally, it still had
some issues as reported by "guix lint". I cleaned them up and also made
some simplifications, removed unnecessary dependencies, and fixed a bug
I observed. I'll make a few comments on v8 for your awareness, but will
also share a v9 with my changes.

Please review v9, and if you agree with the changes mark it as
"reviewed-looks-good". Please see
details on how to add the reviewed-looks-good usertag.

--
Suhail
S
S
Suhail Singh wrote on 5 Oct 05:15 +0200
[PATCH v9] gnu: Add jpm.
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
62a470b969879d779dbd6c77303a71a84193099d.1728096820.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): New variable.

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
Signed-off-by: Suhail <suhail@bayesians.ca>
---
gnu/packages/lisp.scm | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)

Toggle diff (99 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..faa7ed7bed 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -69,6 +70,7 @@ (define-module (gnu packages lisp)
#:use-module (gnu packages bash)
#:use-module (gnu packages bdw-gc)
#:use-module (gnu packages boost)
+ #:use-module (gnu packages certs)
#:use-module (gnu packages check)
#:use-module (gnu packages compression)
#:use-module (gnu packages crypto)
@@ -917,6 +919,74 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ #$gcc "/bin/gcc" "\""))
+ (("\"c\\+\\+\"")
+ (string-append "\""
+ #$gcc "/bin/g++" "\""))
+ (("\"git\"")
+ (string-append "\""
+ #$git "/bin/git" "\""))
+ (("\"curl\"")
+ (string-append "\""
+ #$curl "/bin/curl" "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append #$coreutils "/bin/cp")))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal))
+ (propagated-inputs (list janet
+ git
+ nss-certs
+ ;; Lazily resolve the gcc-toolchain to avoid a
+ ;; circular dependency.
+ (module-ref (resolve-interface '(gnu packages
+ commencement))
+ 'gcc-toolchain)))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description
+ "@code{jpm} is the Janet Project Manager tool. It is a build
+tool and its main uses are installing dependencies, compiling C/C++ to native
+libraries, and other management tasks for Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 73ec844389e91cb0f5a2647070516fc8d19d8730
--
2.46.1
S
S
Suhail Singh wrote on 5 Oct 05:28 +0200
Re: [bug#72925] [PATCH v8] gnu: add jpm package
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87frpbkz2p.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (2 lines)
The URL redirects to https://github.com/janet-lang/jpm.

Toggle quote (5 lines)
> + (("\"cc\"")
> + (string-append "\""
> + (assoc-ref inputs "gcc-toolchain")
> + "/bin/gcc" "\""))

Can be simplified to:
#+begin_src diff
+ (("\"cc\"")
+ (string-append "\""
+ #$gcc "/bin/gcc" "\""))
#+end_src

Toggle quote (2 lines)
> + (("\"c++\"")

This regex doesn't match, it should be "\"c\\+\\+\"".

Toggle quote (4 lines)
> + (string-append "\""
> + (assoc-ref inputs "gcc-toolchain")
> + "/bin/g++" "\""))

Can be similarly simplified. As well for others.

Toggle quote (2 lines)
> + (inputs (list bash-minimal janet))

Since "janet" is in the propagated-inputs, it doesn't need to be
specified in inputs.

Toggle quote (3 lines)
> + (propagated-inputs (list janet
> + coreutils

"coreutils" is not a necessary dependency and can be removed.

Toggle quote (4 lines)
> + git
> + curl
> + nss-certs

"curl" is not necessary either. The combination of "git" and
"nss-certs" when propagated is sufficient

Toggle quote (6 lines)
> + ;; Lazily resolve the gcc-toolchain to avoid
> + ;; a circular dependency.
> + (module-ref (resolve-interface '(gnu packages
> + commencement))
> + 'gcc-toolchain)))

Nicely done! And this one ends up being essential (since it provides
necessary header files etc.).

Toggle quote (3 lines)
> + (description "JPM is the Janet Project Manager tool. It is for automating
> +builds and downloading dependencies of Janet projects.")

I took some liberties with the description based on description on

--
Suhail
S
S
Suhail Singh wrote on 5 Oct 19:21 +0200
[PATCH v10] gnu: Add jpm.
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
6e198e7dc1f64bea3a2b1498fb69e597e4d03360.1728148557.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): New variable.

Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
Signed-off-by: Suhail <suhail@bayesians.ca>
---
gnu/packages/lisp.scm | 77 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)

Toggle diff (113 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..48cf9dffab 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -62,6 +63,7 @@ (define-module (gnu packages lisp)
#:use-module (guix build-system gnu)
#:use-module (guix build-system haskell)
#:use-module (guix build-system trivial)
+ #:use-module ((guix search-paths) #:select ($SSL_CERT_DIR $SSL_CERT_FILE))
#:use-module (gnu packages admin)
#:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
@@ -69,6 +71,7 @@ (define-module (gnu packages lisp)
#:use-module (gnu packages bash)
#:use-module (gnu packages bdw-gc)
#:use-module (gnu packages boost)
+ #:use-module (gnu packages certs)
#:use-module (gnu packages check)
#:use-module (gnu packages compression)
#:use-module (gnu packages crypto)
@@ -917,6 +920,80 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ #$gcc "/bin/gcc" "\""))
+ (("\"c\\+\\+\"")
+ (string-append "\""
+ #$gcc "/bin/g++" "\""))
+ (("\"git\"")
+ (string-append "\""
+ #$git "/bin/git" "\""))
+ (("\"curl\"")
+ (string-append "\""
+ #$curl "/bin/curl" "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append #$coreutils "/bin/cp")))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal))
+ (propagated-inputs (list janet
+ ;; Lazily resolve the gcc-toolchain to avoid a
+ ;; circular dependency.
+ (module-ref (resolve-interface '(gnu packages
+ commencement))
+ 'gcc-toolchain)))
+ ;; NOTE: Below ensures that the user provides the CA certificates they
+ ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
+ ;; isn't recommended) and when they do, that they are respected.
+ ;;
+ ;; FIXME: It's unclear why `search-paths', instead of
+ ;; `native-search-paths', doesn't work.
+ (native-search-paths
+ (list $SSL_CERT_DIR $SSL_CERT_FILE))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description
+ "@code{jpm} is the Janet Project Manager tool. It is a build
+tool and its main uses are installing dependencies, compiling C/C++ to native
+libraries, and other management tasks for Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: 73ec844389e91cb0f5a2647070516fc8d19d8730
--
2.46.1
S
S
Suhail Singh wrote on 5 Oct 19:25 +0200
Re: bug#72925: Adding JPM package for Janet
(address . 72925@debbugs.gnu.org)
878qv2qx5w.fsf_-_@gmail.com
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (7 lines)
>> + git
>> + curl
>> + nss-certs
>
> "curl" is not necessary either. The combination of "git" and
> "nss-certs" when propagated is sufficient

However, it turns out that it's not recommended to bundle nss-certs.
v10 addresses this.

--
Suhail
O
O
Omar Bassam wrote on 6 Oct 15:21 +0200
Re: [PATCH v10] gnu: Add jpm.
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87o73xgyf2.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Thank you Suhail for helping me out wiht this patch. I have some
questions about v10 patch about some parts that I don't fully understand.


Toggle quote (34 lines)
> * gnu/packages/lisp.scm (jpm): New variable.
>
> Change-Id: I730ef2f5c874c5142a580a42af76180e95d93ccd
> Signed-off-by: Suhail <suhail@bayesians.ca>
> ---
> gnu/packages/lisp.scm | 77 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
> index 6c16d8ab71..48cf9dffab 100644
> --- a/gnu/packages/lisp.scm
> +++ b/gnu/packages/lisp.scm
> @@ -29,6 +29,7 @@
> ;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
> ;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
> ;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
> +;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -62,6 +63,7 @@ (define-module (gnu packages lisp)
> #:use-module (guix build-system gnu)
> #:use-module (guix build-system haskell)
> #:use-module (guix build-system trivial)
> + #:use-module ((guix search-paths) #:select ($SSL_CERT_DIR $SSL_CERT_FILE))
> #:use-module (gnu packages admin)
> #:use-module (gnu packages algebra)
> #:use-module (gnu packages autotools)
> @@ -69,6 +71,7 @@ (define-module (gnu packages lisp)
> #:use-module (gnu packages bash)
> #:use-module (gnu packages bdw-gc)
> #:use-module (gnu packages boost)
> + #:use-module (gnu packages certs)

If we don't need nss-verts, do we still need this line?

Toggle quote (66 lines)
> #:use-module (gnu packages check)
> #:use-module (gnu packages compression)
> #:use-module (gnu packages crypto)
> @@ -917,6 +920,80 @@ (define-public janet
> assembler, PEG) is less than 1MB.")
> (license license:expat)))
>
> +(define-public jpm
> + (package
> + (name "jpm")
> + (version "1.1.0")
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/janet-lang/jpm")
> + (commit (string-append "v" version))))
> + (file-name (git-file-name name version))
> + (sha256
> + (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
> + (build-system copy-build-system)
> + (arguments
> + (list
> + #:phases #~(modify-phases %standard-phases
> + (add-after 'unpack 'fix-paths
> + (lambda* (#:key inputs #:allow-other-keys)
> + (substitute* "configs/linux_config.janet"
> + (("/usr/local")
> + #$output)
> + (("\"cc\"")
> + (string-append "\""
> + #$gcc "/bin/gcc" "\""))
> + (("\"c\\+\\+\"")
> + (string-append "\""
> + #$gcc "/bin/g++" "\""))
> + (("\"git\"")
> + (string-append "\""
> + #$git "/bin/git" "\""))
> + (("\"curl\"")
> + (string-append "\""
> + #$curl "/bin/curl" "\"")))
> + (substitute* "jpm/shutil.janet"
> + (("cp")
> + (string-append #$coreutils "/bin/cp")))
> + (setenv "PREFIX"
> + #$output)))
> + (replace 'install
> + (lambda _
> + (for-each (lambda (dir)
> + (mkdir-p (string-append #$output "/" dir)))
> + '("lib/janet/jpm" "share/man/man1"))
> + (invoke "janet" "bootstrap.janet"
> + "configs/linux_config.janet")
> + (wrap-program (string-append #$output "/bin/jpm")
> + `("JANET_HEADERPATH" ":" =
> + (,(string-append #$janet "/include/janet")))
> + `("JANET_LIBPATH" ":" =
> + (,(string-append #$janet "/lib")))))))))
> + (inputs (list bash-minimal))
> + (propagated-inputs (list janet
> + ;; Lazily resolve the gcc-toolchain to avoid a
> + ;; circular dependency.
> + (module-ref (resolve-interface '(gnu packages
> + commencement))
> + 'gcc-toolchain)))

Since we no longer need gcc-toolchain and we are just using gcc
directly, should we remove this module-ref expression and just add gcc as a propagated input?

Toggle quote (4 lines)
> + ;; NOTE: Below ensures that the user provides the CA certificates they
> + ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
> + ;; isn't recommended) and when they do, that they are respected.

Why isn't bundling nss-certs recommended?

Toggle quote (4 lines)
> + ;;
> + ;; FIXME: It's unclear why `search-paths', instead of
> + ;; `native-search-paths', doesn't work.

What are the difference between search-paths and
native-search-paths.
And were you able to run the "jpm install" command
without nss-certs. Because, for me I was unable to do so.
When I added back the nss-certs in propagated-inputs, it worked fine.

Toggle quote (16 lines)
> + (native-search-paths
> + (list $SSL_CERT_DIR $SSL_CERT_FILE))
> + (home-page "https://janet-lang.org/")
> + (synopsis "Janet Project Manager for the Janet programming language")
> + (description
> + "@code{jpm} is the Janet Project Manager tool. It is a build
> +tool and its main uses are installing dependencies, compiling C/C++ to native
> +libraries, and other management tasks for Janet projects.")
> + (license license:expat)))
> +
> (define-public lisp-repl-core-dumper
> (package
> (name "lisp-repl-core-dumper")
>
> base-commit: 73ec844389e91cb0f5a2647070516fc8d19d8730

Sorry I had to send this message twice. This is the first time sending
from gnus in emacs and I didn't know the difference between a "reply"
and a "wide-reply"

BRs,
Omar
S
S
Suhail Singh wrote on 6 Oct 17:46 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87msjh5j5f.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (4 lines)
>> + #:use-module (gnu packages certs)
>
> If we don't need nss-verts, do we still need this line?

Good catch. We don't need this. Please remove in v11 when you send it.

Toggle quote (11 lines)
>> + (propagated-inputs (list janet
>> + ;; Lazily resolve the gcc-toolchain to avoid a
>> + ;; circular dependency.
>> + (module-ref (resolve-interface '(gnu packages
>> + commencement))
>> + 'gcc-toolchain)))
>
> Since we no longer need gcc-toolchain and we are just using gcc
> directly, should we remove this module-ref expression and just add gcc
> as a propagated input?

What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
g++), the compiler is able to locate the appropriate header files.

This should be doable without propagating any other inputs. For example
by ensuring that jpm sets appropriate environment variables (such as
$CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
invoking the compiler. If so, that would be the preferred approach. We
only want to propagate those inputs that are strictly necessary.

I do know that when I had tried to remove gcc-toolchain (without doing
anything else) I encountered some errors during "jpm install -l sh" (in
a pure shell). However, I did not spend any effort in simplifying this,
and I agree that we should try to.

I look forward to seeing what you come up with in v11 :)

Toggle quote (6 lines)
>> + ;; NOTE: Below ensures that the user provides the CA certificates they
>> + ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
>> + ;; isn't recommended) and when they do, that they are respected.
>
> Why isn't bundling nss-certs recommended?

Doing so would deprive the user of the choice of which CAs to trust.
I.e., if we were to bundle nss-certs we are taking an opinionated stance
that the user agrees with Mozilla project's stance on these matters.

Toggle quote (6 lines)
>> + ;; FIXME: It's unclear why `search-paths', instead of
>> + ;; `native-search-paths', doesn't work.
>
> What are the difference between search-paths and
> native-search-paths.

These are documented in the info manual. However, it's not clear to me
_why_ native-search-paths is the right thing to use in this situation.
I posted a message on guix-devel regarding this:

The FIXME was simply an attempt to get the attention of others more
knowledgable than me. Use your discretion regd. whether to keep it or
not.

Toggle quote (4 lines)
> And were you able to run the "jpm install" command without
> nss-certs. Because, for me I was unable to do so. When I added back
> the nss-certs in propagated-inputs, it worked fine.

That is expected behaviour.

The way to test it, when in a pure container, would be by explicitly
ensuring that certificates of trusted CAs are included in the profile.
On way to do so would by adding nss-certs alongside jpm when invoking
the shell.

Relying on the package to provide nss-certs isn't desirable. We simply
want to ensure that when the certs are provided that the package _is
able to use_ them. This is what the native-search-paths line
accomplishes.

--
Suhail
O
O
Omar Bassam wrote on 6 Oct 21:48 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87bjzxgggw.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Hi Suhail,

Sorry, I have more questions.

Toggle quote (36 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>> + #:use-module (gnu packages certs)
>>
>> If we don't need nss-verts, do we still need this line?
>
> Good catch. We don't need this. Please remove in v11 when you send it.
>
>>> + (propagated-inputs (list janet
>>> + ;; Lazily resolve the gcc-toolchain to avoid a
>>> + ;; circular dependency.
>>> + (module-ref (resolve-interface '(gnu packages
>>> + commencement))
>>> + 'gcc-toolchain)))
>>
>> Since we no longer need gcc-toolchain and we are just using gcc
>> directly, should we remove this module-ref expression and just add gcc
>> as a propagated input?
>
> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
> g++), the compiler is able to locate the appropriate header files.
>
> This should be doable without propagating any other inputs. For example
> by ensuring that jpm sets appropriate environment variables (such as
> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
> invoking the compiler. If so, that would be the preferred approach. We
> only want to propagate those inputs that are strictly necessary.
>
> I do know that when I had tried to remove gcc-toolchain (without doing
> anything else) I encountered some errors during "jpm install -l sh" (in
> a pure shell). However, I did not spend any effort in simplifying this,
> and I agree that we should try to.
>
> I look forward to seeing what you come up with in v11 :)
>

I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
commands and the "jpm build" commands worked fine for me without any
issues. I didn't need to set up any C related environemnt variables.
What kind of error where you getting?

Toggle quote (11 lines)
>>> + ;; NOTE: Below ensures that the user provides the CA certificates they
>>> + ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
>>> + ;; isn't recommended) and when they do, that they are respected.
>>
>> Why isn't bundling nss-certs recommended?
>
> Doing so would deprive the user of the choice of which CAs to trust.
> I.e., if we were to bundle nss-certs we are taking an opinionated stance
> that the user agrees with Mozilla project's stance on these matters.
>

But how will the user know that they will need to install nss-certs in
the shell or that they need to setup these SSL environemnt variables?
I agree of giving the user the freedom to enable or disable this but I
truly believe we need to provide sane defaults.

Toggle quote (12 lines)
>>> + ;; FIXME: It's unclear why `search-paths', instead of
>>> + ;; `native-search-paths', doesn't work.
>>
>> What are the difference between search-paths and
>> native-search-paths.
>
> These are documented in the info manual. However, it's not clear to me
> _why_ native-search-paths is the right thing to use in this situation.
> I posted a message on guix-devel regarding this:
> <https://yhetil.org/guix-devel/87zfnipg4b.fsf@gmail.com/>.
>

OK, please let me know when you get to the bottom of this.

Toggle quote (20 lines)
> The FIXME was simply an attempt to get the attention of others more
> knowledgable than me. Use your discretion regd. whether to keep it or
> not.
>
>> And were you able to run the "jpm install" command without
>> nss-certs. Because, for me I was unable to do so. When I added back
>> the nss-certs in propagated-inputs, it worked fine.
>
> That is expected behaviour.
>
> The way to test it, when in a pure container, would be by explicitly
> ensuring that certificates of trusted CAs are included in the profile.
> On way to do so would by adding nss-certs alongside jpm when invoking
> the shell.
>
> Relying on the package to provide nss-certs isn't desirable. We simply
> want to ensure that when the certs are provided that the package _is
> able to use_ them. This is what the native-search-paths line
> accomplishes.

I still don't understand why is it an expected behaviour if jpm by
default is expected to download packages mainly from github?


BRs,
Omar
S
S
Suhail Singh wrote on 6 Oct 23:44 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
8734l86h4l.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (19 lines)
>> This should be doable without propagating any other inputs. For example
>> by ensuring that jpm sets appropriate environment variables (such as
>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>> invoking the compiler. If so, that would be the preferred approach. We
>> only want to propagate those inputs that are strictly necessary.
>>
>> I do know that when I had tried to remove gcc-toolchain (without doing
>> anything else) I encountered some errors during "jpm install -l sh" (in
>> a pure shell). However, I did not spend any effort in simplifying this,
>> and I agree that we should try to.
>>
>> I look forward to seeing what you come up with in v11 :)
>>
>
> I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
> commands and the "jpm build" commands worked fine for me without any
> issues. I didn't need to set up any C related environemnt variables.
> What kind of error where you getting?

I am unable to get the exact message at the moment (due to non-technical
and unrelated reasons), but it was some missing header file.

As I mentioned in the quoted message above, however, what would be
better than propagating gcc, g++ etc would be to ensure that jpm passes
appropriate flags when invoking them. Have you looked into that?

Toggle quote (14 lines)
>>>> + ;; NOTE: Below ensures that the user provides the CA certificates they
>>>> + ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
>>>> + ;; isn't recommended) and when they do, that they are respected.
>>>
>>> Why isn't bundling nss-certs recommended?
>>
>> Doing so would deprive the user of the choice of which CAs to trust.
>> I.e., if we were to bundle nss-certs we are taking an opinionated stance
>> that the user agrees with Mozilla project's stance on these matters.
>>
>
> But how will the user know that they will need to install nss-certs in
> the shell or that they need to setup these SSL environemnt variables?

Are you saying that when you test in a _non-pure_ shell where system
certificates are available, you observe failures?

In pure containers, the failure one observes if the user hasn't done
something to make certificates available is a commonly known occurrence.
See https://issues.guix.gnu.org/70314 for patch to change this default
for networked containers.

Note that if you're not using a pure container, things should just work.
Please correct me if I am mistaken.

Toggle quote (3 lines)
> I agree of giving the user the freedom to enable or disable this but I
> truly believe we need to provide sane defaults.

Bundling nss-certs would depart from the current conventions in Guix (as
I have recently come to understand). For what it's worth, I also (now)
agree that it's not the place for _a package_ to make the determination
of which CAs to trust vs not. However, since I don't have commit
authority, you are welcome to ignore my opinions. My goal was simply to
demonstrate a working patch that didn't depart from current conventions.
I believe I did that.

Perhaps there is a discussion to be had, to revise said conventions
and/or to better understand the tradeoffs of said and related
conventions. However, the guix-devel mailing list may be a better place
for such discussions, and it might help your cause of upstreaming jpm if
those discussions didn't block this patch.

Toggle quote (11 lines)
>>> What are the difference between search-paths and
>>> native-search-paths.
>>
>> These are documented in the info manual. However, it's not clear to me
>> _why_ native-search-paths is the right thing to use in this situation.
>> I posted a message on guix-devel regarding this:
>> <https://yhetil.org/guix-devel/87zfnipg4b.fsf@gmail.com/>.
>>
>
> OK, please let me know when you get to the bottom of this.

I invite you to join the discussion on guix-devel. It's possible that
things that make sense to me, may not to you.

Toggle quote (19 lines)
>>> And were you able to run the "jpm install" command without
>>> nss-certs. Because, for me I was unable to do so. When I added back
>>> the nss-certs in propagated-inputs, it worked fine.
>>
>> That is expected behaviour.
>>
>> The way to test it, when in a pure container, would be by explicitly
>> ensuring that certificates of trusted CAs are included in the profile.
>> On way to do so would by adding nss-certs alongside jpm when invoking
>> the shell.
>>
>> Relying on the package to provide nss-certs isn't desirable. We simply
>> want to ensure that when the certs are provided that the package _is
>> able to use_ them. This is what the native-search-paths line
>> accomplishes.
>
> I still don't understand why is it an expected behaviour if jpm by
> default is expected to download packages mainly from github?

It is the expected behaviour given my understanding of current packaging
practices in Guix. I have nothing more to add beyond what I've already
said on this topic.

Regards,
--
Suhail
O
O
Omar Bassam wrote on 7 Oct 20:24 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
871q0rhiu6.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (29 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>> This should be doable without propagating any other inputs. For example
>>> by ensuring that jpm sets appropriate environment variables (such as
>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>> invoking the compiler. If so, that would be the preferred approach. We
>>> only want to propagate those inputs that are strictly necessary.
>>>
>>> I do know that when I had tried to remove gcc-toolchain (without doing
>>> anything else) I encountered some errors during "jpm install -l sh" (in
>>> a pure shell). However, I did not spend any effort in simplifying this,
>>> and I agree that we should try to.
>>>
>>> I look forward to seeing what you come up with in v11 :)
>>>
>>
>> I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
>> commands and the "jpm build" commands worked fine for me without any
>> issues. I didn't need to set up any C related environemnt variables.
>> What kind of error where you getting?
>
> I am unable to get the exact message at the moment (due to non-technical
> and unrelated reasons), but it was some missing header file.
>
> As I mentioned in the quoted message above, however, what would be
> better than propagating gcc, g++ etc would be to ensure that jpm passes
> appropriate flags when invoking them. Have you looked into that?
>

I am not really an expert in compiling C programs so I'm not sure what
would be the best way to verify this? the "jpm build" command ran fine
for me and I don't have any of those C*PATH environment variables set.

Toggle quote (17 lines)
>>>>> + ;; NOTE: Below ensures that the user provides the CA certificates they
>>>>> + ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
>>>>> + ;; isn't recommended) and when they do, that they are respected.
>>>>
>>>> Why isn't bundling nss-certs recommended?
>>>
>>> Doing so would deprive the user of the choice of which CAs to trust.
>>> I.e., if we were to bundle nss-certs we are taking an opinionated stance
>>> that the user agrees with Mozilla project's stance on these matters.
>>>
>>
>> But how will the user know that they will need to install nss-certs in
>> the shell or that they need to setup these SSL environemnt variables?
>
> Are you saying that when you test in a _non-pure_ shell where system
> certificates are available, you observe failures?

Yes, it did fail initially even in a non-pure non-container shell. I had
to manually set the SSL_CERT_DIR environment variable to /etc/ssl/certs
(I'm on Ubuntu). I did not need to set the SSL_CERT_FILE variable.
Is it possible to set a default value for that environment variable?
I'm not sure though if the /etc/ssl/certs/ is a standard among all Linux
distros or just Ubuntu.

Toggle quote (41 lines)
>
> In pure containers, the failure one observes if the user hasn't done
> something to make certificates available is a commonly known occurrence.
> See <https://issues.guix.gnu.org/70314> for patch to change this default
> for networked containers.
>
> Note that if you're not using a pure container, things should just work.
> Please correct me if I am mistaken.
>
>> I agree of giving the user the freedom to enable or disable this but I
>> truly believe we need to provide sane defaults.
>
> Bundling nss-certs would depart from the current conventions in Guix (as
> I have recently come to understand). For what it's worth, I also (now)
> agree that it's not the place for _a package_ to make the determination
> of which CAs to trust vs not. However, since I don't have commit
> authority, you are welcome to ignore my opinions. My goal was simply to
> demonstrate a working patch that didn't depart from current conventions.
> I believe I did that.
>
> Perhaps there is a discussion to be had, to revise said conventions
> and/or to better understand the tradeoffs of said and related
> conventions. However, the guix-devel mailing list may be a better place
> for such discussions, and it might help your cause of upstreaming jpm if
> those discussions didn't block this patch.
>
>>>> What are the difference between search-paths and
>>>> native-search-paths.
>>>
>>> These are documented in the info manual. However, it's not clear to me
>>> _why_ native-search-paths is the right thing to use in this situation.
>>> I posted a message on guix-devel regarding this:
>>> <https://yhetil.org/guix-devel/87zfnipg4b.fsf@gmail.com/>.
>>>
>>
>> OK, please let me know when you get to the bottom of this.
>
> I invite you to join the discussion on guix-devel. It's possible that
> things that make sense to me, may not to you.
>

Thank you, I'm relatively very new to Guix, so I definitely need to read
involved more about those discussions.

Toggle quote (25 lines)
>>>> And were you able to run the "jpm install" command without
>>>> nss-certs. Because, for me I was unable to do so. When I added back
>>>> the nss-certs in propagated-inputs, it worked fine.
>>>
>>> That is expected behaviour.
>>>
>>> The way to test it, when in a pure container, would be by explicitly
>>> ensuring that certificates of trusted CAs are included in the profile.
>>> On way to do so would by adding nss-certs alongside jpm when invoking
>>> the shell.
>>>
>>> Relying on the package to provide nss-certs isn't desirable. We simply
>>> want to ensure that when the certs are provided that the package _is
>>> able to use_ them. This is what the native-search-paths line
>>> accomplishes.
>>
>> I still don't understand why is it an expected behaviour if jpm by
>> default is expected to download packages mainly from github?
>
> It is the expected behaviour given my understanding of current packaging
> practices in Guix. I have nothing more to add beyond what I've already
> said on this topic.
>
> Regards,

BRs,
Omar
S
S
Suhail Singh wrote on 7 Oct 20:51 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
877cajiw5x.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (17 lines)
>>> I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
>>> commands and the "jpm build" commands worked fine for me without any
>>> issues. I didn't need to set up any C related environemnt variables.
>>> What kind of error where you getting?
>>
>> I am unable to get the exact message at the moment (due to non-technical
>> and unrelated reasons), but it was some missing header file.
>>
>> As I mentioned in the quoted message above, however, what would be
>> better than propagating gcc, g++ etc would be to ensure that jpm passes
>> appropriate flags when invoking them. Have you looked into that?
>>
>
> I am not really an expert in compiling C programs so I'm not sure what
> would be the best way to verify this? the "jpm build" command ran fine
> for me and I don't have any of those C*PATH environment variables set.

When gcc-toolchain is excluded from propagated-inputs, and neither gcc
nor g++ is in propagated-inputs (i.e., propagated-inputs only contains
janet), you *don't* observe a build failure in a _pure_ container where
nss-certs is available while evaluating "jpm install -l sh"?

If so, please let me know and I shall try and reproduce the error I
experienced.

If not, and you are simply stating that things work by propagating gcc
and g++, then we are talking about different things. Specifically, I
was considering what would be needed for eliminating gcc and g++ from
propagated-inputs.

Toggle quote (2 lines)
> Is it possible to set a default value for that environment variable?

Since you already set $JANET_HEADERPATH and $JANET_LIBPATH via
wrap-program, I am not sure I understand the complication you're running
into while trying to provide a default for $SSL_CERT_DIR.

--
Suhail
O
O
Omar Bassam wrote on 7 Oct 21:17 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87ttdng1u1.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (27 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>>> I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
>>>> commands and the "jpm build" commands worked fine for me without any
>>>> issues. I didn't need to set up any C related environemnt variables.
>>>> What kind of error where you getting?
>>>
>>> I am unable to get the exact message at the moment (due to non-technical
>>> and unrelated reasons), but it was some missing header file.
>>>
>>> As I mentioned in the quoted message above, however, what would be
>>> better than propagating gcc, g++ etc would be to ensure that jpm passes
>>> appropriate flags when invoking them. Have you looked into that?
>>>
>>
>> I am not really an expert in compiling C programs so I'm not sure what
>> would be the best way to verify this? the "jpm build" command ran fine
>> for me and I don't have any of those C*PATH environment variables set.
>
> When gcc-toolchain is excluded from propagated-inputs, and neither gcc
> nor g++ is in propagated-inputs (i.e., propagated-inputs only contains
> janet), you *don't* observe a build failure in a _pure_ container where
> nss-certs is available while evaluating "jpm install -l sh"?
>
> If so, please let me know and I shall try and reproduce the error I
> experienced.

Sorry, I didn't fully explain. I meant that instead of doing this
module-ref expression to include "gcc-toolchain", I simply included
"gcc" (which is already imported in lisp.scm) in the propagated-inputs
and it worked fine (in a pure container) for both the "jpm install" and
the "jpm build" command.

Toggle quote (12 lines)
>
> If not, and you are simply stating that things work by propagating gcc
> and g++, then we are talking about different things. Specifically, I
> was considering what would be needed for eliminating gcc and g++ from
> propagated-inputs.
>
>> Is it possible to set a default value for that environment variable?
>
> Since you already set $JANET_HEADERPATH and $JANET_LIBPATH via
> wrap-program, I am not sure I understand the complication you're running
> into while trying to provide a default for $SSL_CERT_DIR.

So you think the following would make sense as a sane default for the
"SSL_CERT_DIR" env variables as an example?

#+begin_src scheme
(native-search-paths
(list (search-path-specification
(variable "SSL_CERT_DIR")
(files (list "/etc/ssl/certs/")))))
#+end_src

I'm not sure what would be a good default for "SSL_CERT_FILE" though.

Thanks,
Omar
S
S
Suhail Singh wrote on 7 Oct 22:15 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
875xq3k6ue.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (14 lines)
>> When gcc-toolchain is excluded from propagated-inputs, and neither gcc
>> nor g++ is in propagated-inputs (i.e., propagated-inputs only contains
>> janet), you *don't* observe a build failure in a _pure_ container where
>> nss-certs is available while evaluating "jpm install -l sh"?
>>
>> If so, please let me know and I shall try and reproduce the error I
>> experienced.
>
> Sorry, I didn't fully explain. I meant that instead of doing this
> module-ref expression to include "gcc-toolchain", I simply included
> "gcc" (which is already imported in lisp.scm) in the propagated-inputs
> and it worked fine (in a pure container) for both the "jpm install" and
> the "jpm build" command.

That not surprising. As I mentioned in my last:

Toggle quote (5 lines)
>> If not, and you are simply stating that things work by propagating gcc
>> and g++, then we are talking about different things. Specifically, I
>> was considering what would be needed for eliminating gcc and g++ from
>> propagated-inputs.

And as I mentioned in a still older message:

Toggle quote (13 lines)
>>>>>> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
>>>>>> g++), the compiler is able to locate the appropriate header files.
>>>>>>
>>>>>> This should be doable without propagating any other inputs. For example
>>>>>> by ensuring that jpm sets appropriate environment variables (such as
>>>>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>>>>> invoking the compiler. If so, that would be the preferred approach. We
>>>>>> only want to propagate those inputs that are strictly necessary.
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> I look forward to seeing what you come up with in v11 :)

I.e., it's not clear to me that propagating gcc and g++ is necessary.
And if the same can be achieved by passing appropriate environment
variables, why not? Could you please answer?

Regardless, we are in agreement that the propagation of gcc-toolchain is
not necessary and should be removed.

Toggle quote (10 lines)
> So you think the following would make sense as a sane default for the
> "SSL_CERT_DIR" env variables as an example?
>
> #+begin_src scheme
> (native-search-paths
> (list (search-path-specification
> (variable "SSL_CERT_DIR")
> (files (list "/etc/ssl/certs/")))))
> #+end_src

I am quite confused. In the v10 I shared, native-search-paths already
includes $SSL_CERT_DIR, whicb if you look at the source is defined as:

#+begin_src scheme
(define $SSL_CERT_DIR
(search-path-specification
(variable "SSL_CERT_DIR")
(separator #f) ;single entry
(files '("etc/ssl/certs"))))
#+end_src

I am no longer sure what problem you are trying to solve.

--
Suhail
O
O
Omar Bassam wrote on 7 Oct 23:08 +0200
[PATCH v11] gnu: Add jpm package.
(address . 72925@debbugs.gnu.org)(name . Omar Bassam)(address . omar.bassam88@gmail.com)
453b1ca8f09ec70707b71557d75dd46ca2299784.1728335255.git.omar.bassam88@gmail.com
* gnu/packages/lisp.scm (jpm): New variable.

Change-Id: I9f5ab89a38622689b5d3545abe5d87906dc61f3b
---
gnu/packages/lisp.scm | 65 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)

Toggle diff (94 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..04b56ea99b 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -62,6 +63,7 @@ (define-module (gnu packages lisp)
#:use-module (guix build-system gnu)
#:use-module (guix build-system haskell)
#:use-module (guix build-system trivial)
+ #:use-module ((guix search-paths) #:select ($SSL_CERT_DIR $SSL_CERT_FILE))
#:use-module (gnu packages admin)
#:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
@@ -917,6 +919,69 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ #$gcc "/bin/gcc" "\""))
+ (("\"c\\+\\+\"")
+ (string-append "\""
+ #$gcc "/bin/g++" "\""))
+ (("\"git\"")
+ (string-append "\""
+ #$git "/bin/git" "\""))
+ (("\"curl\"")
+ (string-append "\""
+ #$curl "/bin/curl" "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append #$coreutils "/bin/cp")))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal))
+ (propagated-inputs (list janet))
+ (native-search-paths
+ (list $SSL_CERT_DIR $SSL_CERT_FILE))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description
+ "@code{jpm} is the Janet Project Manager tool. It is a build
+tool and its main uses are installing dependencies, compiling C/C++ to native
+libraries, and other management tasks for Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")

base-commit: a873666d3bf716a5ae29275efaa000eaf6d1e2a8
--
2.45.2
O
O
Omar Bassam wrote on 7 Oct 23:13 +0200
Re: [PATCH v10] gnu: Add jpm.
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87ed4rfwgw.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Hi Suhail,
I just sent v11 addressing your comments.

Toggle quote (46 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>> When gcc-toolchain is excluded from propagated-inputs, and neither gcc
>>> nor g++ is in propagated-inputs (i.e., propagated-inputs only contains
>>> janet), you *don't* observe a build failure in a _pure_ container where
>>> nss-certs is available while evaluating "jpm install -l sh"?
>>>
>>> If so, please let me know and I shall try and reproduce the error I
>>> experienced.
>>
>> Sorry, I didn't fully explain. I meant that instead of doing this
>> module-ref expression to include "gcc-toolchain", I simply included
>> "gcc" (which is already imported in lisp.scm) in the propagated-inputs
>> and it worked fine (in a pure container) for both the "jpm install" and
>> the "jpm build" command.
>
> That not surprising. As I mentioned in my last:
>
>>> If not, and you are simply stating that things work by propagating gcc
>>> and g++, then we are talking about different things. Specifically, I
>>> was considering what would be needed for eliminating gcc and g++ from
>>> propagated-inputs.
>
> And as I mentioned in a still older message:
>
>>>>>>> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
>>>>>>> g++), the compiler is able to locate the appropriate header files.
>>>>>>>
>>>>>>> This should be doable without propagating any other inputs. For example
>>>>>>> by ensuring that jpm sets appropriate environment variables (such as
>>>>>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>>>>>> invoking the compiler. If so, that would be the preferred approach. We
>>>>>>> only want to propagate those inputs that are strictly necessary.
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> I look forward to seeing what you come up with in v11 :)
>
> I.e., it's not clear to me that propagating gcc and g++ is necessary.
> And if the same can be achieved by passing appropriate environment
> variables, why not? Could you please answer?
>
> Regardless, we are in agreement that the propagation of gcc-toolchain is
> not necessary and should be removed.
>

I've now removed gcc from the propagated-inputs I've tested passing the
gcc to jpm using the --cc flag as follows "jpm build --cc=/path/to/gcc".
I hope I understood your concern correctly this time. If not, please
feel free to add to the patch whatever you think is needed as I'm not a
C compiling expert.

Toggle quote (23 lines)
>> So you think the following would make sense as a sane default for the
>> "SSL_CERT_DIR" env variables as an example?
>>
>> #+begin_src scheme
>> (native-search-paths
>> (list (search-path-specification
>> (variable "SSL_CERT_DIR")
>> (files (list "/etc/ssl/certs/")))))
>> #+end_src
>
> I am quite confused. In the v10 I shared, native-search-paths already
> includes $SSL_CERT_DIR, whicb if you look at the source is defined as:
>
> #+begin_src scheme
> (define $SSL_CERT_DIR
> (search-path-specification
> (variable "SSL_CERT_DIR")
> (separator #f) ;single entry
> (files '("etc/ssl/certs"))))
> #+end_src
>
> I am no longer sure what problem you are trying to solve.

Sorry, I now looked at the code and understand what it's doing.

Thanks again,
Omar
S
S
Suhail Singh wrote on 8 Oct 02:11 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87y12zh2rx.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (24 lines)
>>>>>>>> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
>>>>>>>> g++), the compiler is able to locate the appropriate header files.
>>>>>>>>
>>>>>>>> This should be doable without propagating any other inputs. For example
>>>>>>>> by ensuring that jpm sets appropriate environment variables (such as
>>>>>>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>>>>>>> invoking the compiler. If so, that would be the preferred approach. We
>>>>>>>> only want to propagate those inputs that are strictly necessary.
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> I look forward to seeing what you come up with in v11 :)
>>
>> I.e., it's not clear to me that propagating gcc and g++ is necessary.
>> And if the same can be achieved by passing appropriate environment
>> variables, why not? Could you please answer?
>>
>> Regardless, we are in agreement that the propagation of gcc-toolchain is
>> not necessary and should be removed.
>>
>
> I've now removed gcc from the propagated-inputs I've tested passing the
> gcc to jpm using the --cc flag as follows "jpm build --cc=/path/to/gcc".

Am I understanding correctly that, with v11 in order for the user to be
able to install a Janet package such as "sh", they have to find the
location of gcc being used by jpm and pass that to it?

If so, why? This is not what I tried to explain above. The jpm package
"knows" the specific version of gcc (and g++) that have been patched in,
so why does it require the user to take additional action? I.e., the
goal, IMHO, should be that in a pure container that contains nss-certs,
one is simply able to run "jpm install -l sh" and it works.

Toggle quote (2 lines)
> I hope I understood your concern correctly this time.

I don't believe so.

Toggle quote (3 lines)
> If not, please feel free to add to the patch whatever you think is
> needed as I'm not a C compiling expert.

Sorry, but I am no C compiling expert either.

In addition, for the past few exchanges, it's not clear that I am able
to bring value to the discussion. As evidenced by the recent exchanges,
I seem to be struggling with expressing myself effectively. As such, I
will step-away from actively reviewing this issue.

I hope you are able to get jpm upstreamed with help from jgart and
others more experienced than myself.

--
Suhail
S
S
Suhail Singh wrote on 8 Oct 02:15 +0200
control message for bug #72925
(address . control@debbugs.gnu.org)
87v7y3h2ku.fsf@gmail.com
noowner 72925
user guix
usertag 72925 - under-review
usertag 72925 + escalated-review-request
quit
S
S
Suhail Singh wrote on 8 Oct 05:49 +0200
Re: [PATCH v10] gnu: Add jpm.
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87r08rgsoy.fsf@gmail.com
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (10 lines)
>> If not, please feel free to add to the patch whatever you think is
>> needed as I'm not a C compiling expert.
>
> Sorry, but I am no C compiling expert either.
>
> In addition, for the past few exchanges, it's not clear that I am able
> to bring value to the discussion. As evidenced by the recent exchanges,
> I seem to be struggling with expressing myself effectively. As such, I
> will step-away from actively reviewing this issue.

Having stepped away as the reviewer, and since I had a few minutes to
spare this evening, I decided to go ahead and implement what I had in
mind. It was quite straightforward.

I'll submit it shortly in the form of a patch series with my changes in
a separate patch. That should make it easy to discard or incorporate my
proposed changes as desired.

Toggle quote (3 lines)
> I hope you are able to get jpm upstreamed with help from jgart and
> others more experienced than myself.

This sentiment still stands, with or without my revisions.

--
Suhail
S
S
Suhail Singh wrote on 8 Oct 06:13 +0200
[PATCH v12 0/2] gnu: Add jpm package.
(address . 72925@debbugs.gnu.org)
cover.1728359428.git.suhail@bayesians.ca
Hello Guix,

This revision adds some changes to Omar's patch for adding JPM to Guix.

Since I am not an experienced Guix user, nor do I frequently deal
directly with GCC, it is possible that the revisions I introduce in the
second patch are misguided. I request someone with more (relevant)
experience to review these and make the determination on whether or not
the changes I introduce ought to be accepted as is, modified, or
rejected outright. If rejected, please share a summary of the reasons.

AFAIU, jpm invokes gcc/g++ in order to compile Janet modules. With my
changes, in a pure container with networking enabled and nss-certs
available the below commands succeed:

- jpm install -l sh
- jpm install -l spork

Without my changes, the invocation in the first item above (without
additional flags being passed by the user) fails due to missing header
files (<linux/falloc.h>).

Regards,
Suhail

Omar Bassam (1):
gnu: Add jpm package.

Suhail (1):
gnu: Improve user-experience for jpm.

gnu/packages/lisp.scm | 82 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)


base-commit: 73ec844389e91cb0f5a2647070516fc8d19d8730
--
2.46.1
S
S
Suhail Singh wrote on 8 Oct 06:14 +0200
[PATCH v12 1/2] gnu: Add jpm package.
(address . 72925@debbugs.gnu.org)
dd8367abe00f42520de4e92d1bc45443ad65cfa5.1728359428.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): New variable.

Change-Id: I9f5ab89a38622689b5d3545abe5d87906dc61f3b
Signed-off-by: Suhail <suhail@bayesians.ca>
---
gnu/packages/lisp.scm | 65 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)

Toggle diff (92 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..04b56ea99b 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -62,6 +63,7 @@ (define-module (gnu packages lisp)
#:use-module (guix build-system gnu)
#:use-module (guix build-system haskell)
#:use-module (guix build-system trivial)
+ #:use-module ((guix search-paths) #:select ($SSL_CERT_DIR $SSL_CERT_FILE))
#:use-module (gnu packages admin)
#:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
@@ -917,6 +919,69 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ #$gcc "/bin/gcc" "\""))
+ (("\"c\\+\\+\"")
+ (string-append "\""
+ #$gcc "/bin/g++" "\""))
+ (("\"git\"")
+ (string-append "\""
+ #$git "/bin/git" "\""))
+ (("\"curl\"")
+ (string-append "\""
+ #$curl "/bin/curl" "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append #$coreutils "/bin/cp")))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal))
+ (propagated-inputs (list janet))
+ (native-search-paths
+ (list $SSL_CERT_DIR $SSL_CERT_FILE))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description
+ "@code{jpm} is the Janet Project Manager tool. It is a build
+tool and its main uses are installing dependencies, compiling C/C++ to native
+libraries, and other management tasks for Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")
--
2.46.1
S
S
Suhail Singh wrote on 8 Oct 06:16 +0200
[PATCH v12 2/2] gnu: Improve user-experience for jpm.
(address . 72925@debbugs.gnu.org)
4665e2a478a63cf0bc6b8a18a2fb44687298bbd7.1728359428.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): Ensure jpm respects JANET_HEADERPATH and
JANET_LIBPATH if set by user. Ensure gcc/g++ is able to find header files and
compilation-related utilities.

Change-Id: Ic7218dbd10e6fabddded50894b82492de8cabc88
---
gnu/packages/lisp.scm | 31 ++++++++++++++++++++++++-------
1 file changed, 24 insertions(+), 7 deletions(-)

Toggle diff (56 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 04b56ea99b..4223540913 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -30,6 +30,7 @@
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
+;;; Copyright © 2024 Suhail Singh <suhail@bayesians.ca>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -959,18 +960,34 @@ (define-public jpm
(setenv "PREFIX"
#$output)))
(replace 'install
- (lambda _
+ (lambda* (#:key inputs #:allow-other-keys)
(for-each (lambda (dir)
(mkdir-p (string-append #$output "/" dir)))
'("lib/janet/jpm" "share/man/man1"))
(invoke "janet" "bootstrap.janet"
"configs/linux_config.janet")
- (wrap-program (string-append #$output "/bin/jpm")
- `("JANET_HEADERPATH" ":" =
- (,(string-append #$janet "/include/janet")))
- `("JANET_LIBPATH" ":" =
- (,(string-append #$janet "/lib")))))))))
- (inputs (list bash-minimal))
+ (let ((gcc-toolchain (assoc-ref inputs "gcc-toolchain")))
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" prefix
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" prefix
+ (,(string-append #$janet "/lib")))
+ `("C_INCLUDE_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/include")))
+ `("CPLUS_INCLUDE_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/include/c++")
+ ,(string-append gcc-toolchain "/include")))
+ `("LIBRARY_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/lib")
+ ,(string-append gcc-toolchain "/lib64")))
+ `("PATH" ":" prefix
+ (,(string-append gcc-toolchain "/bin")
+ ,(string-append #$coreutils "/bin"))))))))))
+ (inputs (list bash-minimal
+ ;; Lazily resolve the gcc-toolchain to avoid a circular
+ ;; dependency.
+ (module-ref (resolve-interface '(gnu packages commencement))
+ 'gcc-toolchain)))
(propagated-inputs (list janet))
(native-search-paths
(list $SSL_CERT_DIR $SSL_CERT_FILE))
--
2.46.1
O
O
Omar Bassam wrote on 8 Oct 10:25 +0200
Re: [PATCH v10] gnu: Add jpm.
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87a5fff1bu.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (37 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>>>>>>>> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
>>>>>>>>> g++), the compiler is able to locate the appropriate header files.
>>>>>>>>>
>>>>>>>>> This should be doable without propagating any other inputs. For example
>>>>>>>>> by ensuring that jpm sets appropriate environment variables (such as
>>>>>>>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>>>>>>>> invoking the compiler. If so, that would be the preferred approach. We
>>>>>>>>> only want to propagate those inputs that are strictly necessary.
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> I look forward to seeing what you come up with in v11 :)
>>>
>>> I.e., it's not clear to me that propagating gcc and g++ is necessary.
>>> And if the same can be achieved by passing appropriate environment
>>> variables, why not? Could you please answer?
>>>
>>> Regardless, we are in agreement that the propagation of gcc-toolchain is
>>> not necessary and should be removed.
>>>
>>
>> I've now removed gcc from the propagated-inputs I've tested passing the
>> gcc to jpm using the --cc flag as follows "jpm build --cc=/path/to/gcc".
>
> Am I understanding correctly that, with v11 in order for the user to be
> able to install a Janet package such as "sh", they have to find the
> location of gcc being used by jpm and pass that to it?
>
> If so, why? This is not what I tried to explain above. The jpm package
> "knows" the specific version of gcc (and g++) that have been patched in,
> so why does it require the user to take additional action? I.e., the
> goal, IMHO, should be that in a pure container that contains nss-certs,
> one is simply able to run "jpm install -l sh" and it works.
>

No, the user doesn't need to specify the flag if the gcc package is
available in their shell (or pure container shell). I was just testing
that you can pass the C flags that you were concerned about from before.
I am still not sure if I fully understood your C paths cocern correctly.

Toggle quote (15 lines)
>> I hope I understood your concern correctly this time.
>
> I don't believe so.
>
>> If not, please feel free to add to the patch whatever you think is
>> needed as I'm not a C compiling expert.
>
> Sorry, but I am no C compiling expert either.
>
> In addition, for the past few exchanges, it's not clear that I am able
> to bring value to the discussion. As evidenced by the recent exchanges,
> I seem to be struggling with expressing myself effectively. As such, I
> will step-away from actively reviewing this issue.
>

On the contrary, I've learned so much from your comments and I really
appreciate your patience. I believe it's my lack of understanding of
guix packagin philosophy as this is my first time diving into the source
code of Guix.

Toggle quote (3 lines)
> I hope you are able to get jpm upstreamed with help from jgart and
> others more experienced than myself.

Thank you, if it ever get upstreamed it will be mostly becuase of your
comments, knowledge sharing and patience that I really appreciate.

Many Thanks,
Omar
S
S
Suhail Singh wrote on 8 Oct 15:39 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
877cai7lxx.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (3 lines)
> ... if the gcc package is available in their shell (or pure container
> shell).

In v12, the testing container does _not_ need to provide gcc, g++,
gcc-toolchain etc. It only needs to provide nss-certs in addition to
some usable shell environment.

Toggle quote (2 lines)
> I am still not sure if I fully understood your C paths cocern correctly.

You may see v12 if curious.

--
Suhail
O
O
Omar Bassam wrote on 8 Oct 18:33 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
875xq2ftbd.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (9 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>> ... if the gcc package is available in their shell (or pure container
>> shell).
>
> In v12, the testing container does _not_ need to provide gcc, g++,
> gcc-toolchain etc. It only needs to provide nss-certs in addition to
> some usable shell environment.

Can you give me an example of what guix shell commands I need to run to
test these.

Toggle quote (5 lines)
>
>> I am still not sure if I fully understood your C paths cocern correctly.
>
> You may see v12 if curious.

For some reason I didn't receive an email for v12. I just saw it on the
issues website and I now understand better what you meant from before.
It makes much more sense for me now.

Thanks,
Omar
S
S
Suhail Singh wrote on 9 Oct 00:01 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87iku245lb.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (3 lines)
> Can you give me an example of what guix shell commands I need to run to
> test these.

I already have.

Given a profile containing only bash, coreutils-minimal, and nss-certs,
one can launch an interactive shell via snippet I shared in
they can navigate to /tmp and test jpm by using it to install packages
locally as noted in

I don't understand what's unclear.

--
Suhail
O
O
Omar Bassam wrote on 9 Oct 13:58 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
871q0pfpy5.fsf@omar-Latitude-5540.mail-host-address-is-not-set
Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (7 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>> Can you give me an example of what guix shell commands I need to run to
>> test these.
>
> I already have.

Yes, sorry I thought you were going to use other commands to test these
C*PATH variables.

Toggle quote (10 lines)
>
> Given a profile containing only bash, coreutils-minimal, and nss-certs,
> one can launch an interactive shell via snippet I shared in
> <https://yhetil.org/guix/87jzep2tlb.fsf_-_@gmail.com/>. Having done so
> they can navigate to /tmp and test jpm by using it to install packages
> locally as noted in
> <https://yhetil.org/guix/cover.1728359428.git.suhail@bayesians.ca/>.
>
> I don't understand what's unclear.

It's clear now, thanks. I've tested v12 and it works without any issues
for both the "jpm install" and the "jpm build command".

Many Thanks,
Omar
S
S
Suhail Singh wrote on 9 Oct 15:12 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87ttdl773x.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (3 lines)
> Yes, sorry I thought you were going to use other commands to test these
> C*PATH variables.

No, installation in a pure container with minimal dependencies is the
only automated test I've done (given my lack of familiarity with jpm and
Janet). However, I did manually inspect the generated jpm script in the
store to check that the variables were being set in a reasonable manner.

--
Suhail
O
O
Omar Bassam wrote on 9 Oct 18:49 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)(address . 72925@debbugs.gnu.org)
CAGSr2rboNsxvsibnbJZxsXruGfgKS6Tm1B-cGk+hzjAiTKU5xA@mail.gmail.com
That's good to hear.
So is this patch now done and ready to be merged? or do we need something
else?

On Wed, 9 Oct 2024 at 16:12, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (13 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > Yes, sorry I thought you were going to use other commands to test these
> > C*PATH variables.
>
> No, installation in a pure container with minimal dependencies is the
> only automated test I've done (given my lack of familiarity with jpm and
> Janet). However, I did manually inspect the generated jpm script in the
> store to check that the variables were being set in a reasonable manner.
>
> --
> Suhail
>
Attachment: file
S
S
Suhail Singh wrote on 9 Oct 19:15 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87plo96vub.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (2 lines)
> So is this patch now done

I have nothing to add other than what I did in v12. I don't know if
that means it's "done".

Toggle quote (2 lines)
> and ready to be merged?

That's a question for others more experienced than myself, and probably
for someone with commit access.

Toggle quote (2 lines)
> or do we need something else?

See above.

--
Suhail
O
O
Omar Bassam wrote on 11 Oct 18:23 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)(address . 72925@debbugs.gnu.org)
CAGSr2rZDjaDB_Hm5=XjAaDMudQYHF8Db6KNc8BVA20fbhHtFtA@mail.gmail.com
On Wed, 9 Oct 2024 at 20:15, Suhail Singh <suhailsingh247@gmail.com> wrote:

Toggle quote (8 lines)
> Omar Bassam <omar.bassam88@gmail.com> writes:
>
> > So is this patch now done
>
> I have nothing to add other than what I did in v12. I don't know if
> that means it's "done".
>
>
I think so, I've tested different commands with installing and building
janet packages and it worked flawlessly.


Toggle quote (6 lines)
> > and ready to be merged?
>
> That's a question for others more experienced than myself, and probably
> for someone with commit access.
>
>
So, how can we know who we need to contact to ask for a review?

Toggle quote (7 lines)
> or do we need something else?
>
> See above.
>
> --
> Suhail
>
Attachment: file
S
S
Suhail Singh wrote on 11 Oct 18:45 +0200
(name . Omar Bassam)(address . omar.bassam88@gmail.com)
87r08mlhaj.fsf@gmail.com
Omar Bassam <omar.bassam88@gmail.com> writes:

Toggle quote (2 lines)
> So, how can we know who we need to contact to ask for a review?

See the output of "./etc/teams.scm list-members lisp". If unaware,
please see the relevant guideline in the manual [1] to ensure that the
relevant team is notified when submitting patches.

For what it's worth, the X-Debbugs-Cc header included their addresses
when I sent v12, so they should've been notified.

[1]: (info "(guix) Teams")

--
Suhail
L
L
Ludovic Courtès wrote on 12 Oct 19:18 +0200
Re: bug#72925: Adding JPM package for Janet
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87plo5s0i9.fsf_-_@gnu.org
Hi,

Suhail Singh <suhailsingh247@gmail.com> skribis:

Toggle quote (5 lines)
> * gnu/packages/lisp.scm (jpm): New variable.
>
> Change-Id: I9f5ab89a38622689b5d3545abe5d87906dc61f3b
> Signed-off-by: Suhail <suhail@bayesians.ca>

There’s already been a lot of work and many versions, so I feel bad
asking for more changes, but here I am…

Toggle quote (24 lines)
> + (arguments
> + (list
> + #:phases #~(modify-phases %standard-phases
> + (add-after 'unpack 'fix-paths
> + (lambda* (#:key inputs #:allow-other-keys)
> + (substitute* "configs/linux_config.janet"
> + (("/usr/local")
> + #$output)
> + (("\"cc\"")
> + (string-append "\""
> + #$gcc "/bin/gcc" "\""))
> + (("\"c\\+\\+\"")
> + (string-append "\""
> + #$gcc "/bin/g++" "\""))
> + (("\"git\"")
> + (string-append "\""
> + #$git "/bin/git" "\""))
> + (("\"curl\"")
> + (string-append "\""
> + #$curl "/bin/curl" "\"")))
> + (substitute* "jpm/shutil.janet"
> + (("cp")
> + (string-append #$coreutils "/bin/cp")))

Please add ‘git-minimal/pinned’, ‘curl’, and ‘coreutils-minimal’ to the
‘inputs’ field. Then you can fix the stanzas above to things like:

(string-append "\"" (search-input-file inputs "/bin/curl") "\"")

Likewise for GCC, but see next message.

Ludo’.
L
L
Ludovic Courtès wrote on 12 Oct 19:22 +0200
(name . Suhail Singh)(address . suhailsingh247@gmail.com)
87ldyts0cm.fsf_-_@gnu.org
Suhail Singh <suhailsingh247@gmail.com> skribis:

Toggle quote (6 lines)
> * gnu/packages/lisp.scm (jpm): Ensure jpm respects JANET_HEADERPATH and
> JANET_LIBPATH if set by user. Ensure gcc/g++ is able to find header files and
> compilation-related utilities.
>
> Change-Id: Ic7218dbd10e6fabddded50894b82492de8cabc88

[...]

Toggle quote (22 lines)
> + (wrap-program (string-append #$output "/bin/jpm")
> + `("JANET_HEADERPATH" ":" prefix
> + (,(string-append #$janet "/include/janet")))
> + `("JANET_LIBPATH" ":" prefix
> + (,(string-append #$janet "/lib")))
> + `("C_INCLUDE_PATH" ":" prefix
> + (,(string-append gcc-toolchain "/include")))
> + `("CPLUS_INCLUDE_PATH" ":" prefix
> + (,(string-append gcc-toolchain "/include/c++")
> + ,(string-append gcc-toolchain "/include")))
> + `("LIBRARY_PATH" ":" prefix
> + (,(string-append gcc-toolchain "/lib")
> + ,(string-append gcc-toolchain "/lib64")))
> + `("PATH" ":" prefix
> + (,(string-append gcc-toolchain "/bin")
> + ,(string-append #$coreutils "/bin"))))))))))
> + (inputs (list bash-minimal
> + ;; Lazily resolve the gcc-toolchain to avoid a circular
> + ;; dependency.
> + (module-ref (resolve-interface '(gnu packages commencement))
> + 'gcc-toolchain)))

I suppose JPM shells out to GCC to compiler Janet (or C?) code, right?

I’d recommend adding ‘gcc’, ‘glibc’, ‘binutils’, and ‘ld-wrapper’ to
‘inputs’; that’d less us avoid the ‘gcc-toolchain’ dance.

Then in, the phase above, make sure to ‘search-input-file’ rather than
direct references to these variables.

How does that sound?

Alternatively, depending on how important this is for JPM, you could
also leave it up to users to install ‘gcc-toolchain’ alongside JPM when
they need it.

Thanks,
Ludo’.
S
S
Suhail Singh wrote on 12 Oct 22:17 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
87iktxuld4.fsf@gmail.com
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (12 lines)
>> + (("\"curl\"")
>> + (string-append "\""
>> + #$curl "/bin/curl" "\"")))
>> + (substitute* "jpm/shutil.janet"
>> + (("cp")
>> + (string-append #$coreutils "/bin/cp")))
>
> Please add ‘git-minimal/pinned’, ‘curl’, and ‘coreutils-minimal’ to the
> ‘inputs’ field. Then you can fix the stanzas above to things like:
>
> (string-append "\"" (search-input-file inputs "/bin/curl") "\"")

Happy to make the requested changes.

Could you please, however, elaborate on the guiding principle here?
I.e., what's the "lesson" here? It seems that the preference is for
search-input-file over gexps such as #$curl, but it's not clear what
makes it the preferred approach.

--
Suhail
S
S
Suhail Singh wrote on 12 Oct 22:22 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ed4lul3w.fsf@gmail.com
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (2 lines)
> I suppose JPM shells out to GCC to compiler Janet (or C?) code, right?

Yes.

Toggle quote (8 lines)
> I’d recommend adding ‘gcc’, ‘glibc’, ‘binutils’, and ‘ld-wrapper’ to
> ‘inputs’; that’d less us avoid the ‘gcc-toolchain’ dance.
>
> Then in, the phase above, make sure to ‘search-input-file’ rather than
> direct references to these variables.
>
> How does that sound?

Sounds good.

Toggle quote (4 lines)
> Alternatively, depending on how important this is for JPM, you could
> also leave it up to users to install ‘gcc-toolchain’ alongside JPM when
> they need it.

It's a pretty essential dependency for JPM, so adding gcc, glibc etc to
inputs would be preferable.

I'll submit v13 shortly. I look forward to your elaboration on why
direct references aren't preferable. Thank you for taking the time to
review.

--
Suhail
S
S
Suhail Singh wrote on 12 Oct 23:14 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
875xpxuipi.fsf@gmail.com
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (27 lines)
>> + (wrap-program (string-append #$output "/bin/jpm")
>> + `("JANET_HEADERPATH" ":" prefix
>> + (,(string-append #$janet "/include/janet")))
>> + `("JANET_LIBPATH" ":" prefix
>> + (,(string-append #$janet "/lib")))
>> + `("C_INCLUDE_PATH" ":" prefix
>> + (,(string-append gcc-toolchain "/include")))
>> + `("CPLUS_INCLUDE_PATH" ":" prefix
>> + (,(string-append gcc-toolchain "/include/c++")
>> + ,(string-append gcc-toolchain "/include")))
>> + `("LIBRARY_PATH" ":" prefix
>> + (,(string-append gcc-toolchain "/lib")
>> + ,(string-append gcc-toolchain "/lib64")))
>> + `("PATH" ":" prefix
>> + (,(string-append gcc-toolchain "/bin")
>> + ,(string-append #$coreutils "/bin"))))))))))
>> + (inputs (list bash-minimal
>> + ;; Lazily resolve the gcc-toolchain to avoid a circular
>> + ;; dependency.
>> + (module-ref (resolve-interface '(gnu packages commencement))
>> + 'gcc-toolchain)))
>
> I suppose JPM shells out to GCC to compiler Janet (or C?) code, right?
>
> I’d recommend adding ‘gcc’, ‘glibc’, ‘binutils’, and ‘ld-wrapper’ to
> ‘inputs’; that’d less us avoid the ‘gcc-toolchain’ dance.

It seems "ld-wrapper" requires (gnu packages commencement) and this
results in doing the lazy dereference similar to gcc-toolchain above.
Am I doing something wrong? If not, is the guidance still to add
"ld-wrapper" to inputs?

Toggle quote (3 lines)
> Then in, the phase above, make sure to ‘search-input-file’ rather than
> direct references to these variables.

Hmm just to be clear, instead of:

#+begin_src scheme
`("C_INCLUDE_PATH" ":" prefix
(,(string-append gcc-toolchain "/include")))
#+end_src

What we want is something like:

#+begin_src scheme
`("C_INCLUDE_PATH" ":" prefix
(,(search-input-file inputs "/include")))
#+end_src

Is my understanding correct?

If so, adding "gcc", "glibc", "binutils", and "ld-wrapper" seems
insufficient to make that work. The search-input-file for "/include"
results in a "&search-error" when building the package.

--
Suhail
S
S
Suhail Singh wrote on 14 Oct 19:25 +0200
[PATCH v13 1/2] gnu: Add jpm package.
(address . 72925@debbugs.gnu.org)
9936b453a5f36ad3addca7e4d5dae36a97a855d9.1728925129.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): New variable.

Change-Id: I9f5ab89a38622689b5d3545abe5d87906dc61f3b
Signed-off-by: Suhail <suhail@bayesians.ca>
---
gnu/packages/lisp.scm | 73 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)

Toggle diff (100 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 6c16d8ab71..7b557fc493 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -29,6 +29,7 @@
;;; Copyright © 2024 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
+;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -62,6 +63,7 @@ (define-module (gnu packages lisp)
#:use-module (guix build-system gnu)
#:use-module (guix build-system haskell)
#:use-module (guix build-system trivial)
+ #:use-module ((guix search-paths) #:select ($SSL_CERT_DIR $SSL_CERT_FILE))
#:use-module (gnu packages admin)
#:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
@@ -917,6 +919,77 @@ (define-public janet
assembler, PEG) is less than 1MB.")
(license license:expat)))
+(define-public jpm
+ (package
+ (name "jpm")
+ (version "1.1.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/janet-lang/jpm")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "05rdxigmiy7vf93s16a8n2029lq33073jccz1rjl4iisxj6piw4l"))))
+ (build-system copy-build-system)
+ (arguments
+ (list
+ #:phases #~(modify-phases %standard-phases
+ (add-after 'unpack 'fix-paths
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "configs/linux_config.janet"
+ (("/usr/local")
+ #$output)
+ (("\"cc\"")
+ (string-append "\""
+ (search-input-file inputs "/bin/gcc")
+ "\""))
+ (("\"c\\+\\+\"")
+ (string-append "\""
+ (search-input-file inputs "/bin/g++")
+ "\""))
+ (("\"git\"")
+ (string-append "\""
+ (search-input-file inputs "/bin/git")
+ "\""))
+ (("\"curl\"")
+ (string-append "\""
+ (search-input-file inputs "/bin/curl")
+ "\"")))
+ (substitute* "jpm/shutil.janet"
+ (("cp")
+ (string-append (search-input-file inputs "/bin/cp"))))
+ (setenv "PREFIX"
+ #$output)))
+ (replace 'install
+ (lambda _
+ (for-each (lambda (dir)
+ (mkdir-p (string-append #$output "/" dir)))
+ '("lib/janet/jpm" "share/man/man1"))
+ (invoke "janet" "bootstrap.janet"
+ "configs/linux_config.janet")
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" =
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" =
+ (,(string-append #$janet "/lib")))))))))
+ (inputs (list bash-minimal
+ coreutils-minimal
+ curl
+ gcc
+ git-minimal/pinned))
+ (propagated-inputs (list janet))
+ (native-search-paths
+ (list $SSL_CERT_DIR $SSL_CERT_FILE))
+ (home-page "https://janet-lang.org/")
+ (synopsis "Janet Project Manager for the Janet programming language")
+ (description
+ "@code{jpm} is the Janet Project Manager tool. It is a build
+tool and its main uses are installing dependencies, compiling C/C++ to native
+libraries, and other management tasks for Janet projects.")
+ (license license:expat)))
+
(define-public lisp-repl-core-dumper
(package
(name "lisp-repl-core-dumper")
--
2.47.0
S
S
Suhail Singh wrote on 14 Oct 19:26 +0200
[PATCH v13 2/2] gnu: Improve user-experience for jpm.
(address . 72925@debbugs.gnu.org)
3cbf3de67871ab5aa7771d146e4dcdcef1a3e880.1728925129.git.suhail@bayesians.ca
* gnu/packages/lisp.scm (jpm): Ensure jpm respects JANET_HEADERPATH and
JANET_LIBPATH if set by user. Ensure gcc/g++ is able to find header files and
compilation-related utilities.

Change-Id: Ic7218dbd10e6fabddded50894b82492de8cabc88
---
gnu/packages/lisp.scm | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)

Toggle diff (61 lines)
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 7b557fc493..1cc8390f6b 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -30,6 +30,7 @@
;;; Copyright © 2024 bigbug <bigbookofbug@proton.me>
;;; Copyright © 2024 Ashish SHUKLA <ashish.is@lostca.se>
;;; Copyright © 2024 Omar Bassam <omar.bassam88@gmail.com>
+;;; Copyright © 2024 Suhail Singh <suhail@bayesians.ca>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -963,22 +964,39 @@ (define-public jpm
(setenv "PREFIX"
#$output)))
(replace 'install
- (lambda _
+ (lambda* (#:key inputs #:allow-other-keys)
(for-each (lambda (dir)
(mkdir-p (string-append #$output "/" dir)))
'("lib/janet/jpm" "share/man/man1"))
(invoke "janet" "bootstrap.janet"
"configs/linux_config.janet")
- (wrap-program (string-append #$output "/bin/jpm")
- `("JANET_HEADERPATH" ":" =
- (,(string-append #$janet "/include/janet")))
- `("JANET_LIBPATH" ":" =
- (,(string-append #$janet "/lib")))))))))
+ (let ((gcc-toolchain (assoc-ref inputs "gcc-toolchain"))
+ (core-min (assoc-ref inputs "coreutils-minimal")))
+ (wrap-program (string-append #$output "/bin/jpm")
+ `("JANET_HEADERPATH" ":" prefix
+ (,(string-append #$janet "/include/janet")))
+ `("JANET_LIBPATH" ":" prefix
+ (,(string-append #$janet "/lib")))
+ `("C_INCLUDE_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/include")))
+ `("CPLUS_INCLUDE_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/include/c++")
+ ,(string-append gcc-toolchain "/include")))
+ `("LIBRARY_PATH" ":" prefix
+ (,(string-append gcc-toolchain "/lib")
+ ,(string-append gcc-toolchain "/lib64")))
+ `("PATH" ":" prefix
+ (,(string-append gcc-toolchain "/bin")
+ ,(string-append core-min "/bin"))))))))))
(inputs (list bash-minimal
coreutils-minimal
curl
gcc
- git-minimal/pinned))
+ git-minimal/pinned
+ ;; Lazily resolve the gcc-toolchain to avoid a circular
+ ;; dependency.
+ (module-ref (resolve-interface '(gnu packages commencement))
+ 'gcc-toolchain)))
(propagated-inputs (list janet))
(native-search-paths
(list $SSL_CERT_DIR $SSL_CERT_FILE))
--
2.47.0
S
S
Suhail Singh wrote on 14 Oct 19:23 +0200
[PATCH v13 0/2] Add jpm.
(address . 72925@debbugs.gnu.org)
cover.1728925129.git.suhail@bayesians.ca
Hi,

This version incorporates one feedback from Ludo
(https://issues.guix.gnu.org/72925#61), however, I was unable to
incorporate the changes suggested in the second comment regarding
gcc-toolchain (https://issues.guix.gnu.org/72925#62). I posted some
clarifying questions in https://issues.guix.gnu.org/72925#65.

Since, I will have limited availability in the next ~1-2 weeks I am
sharing the current state for everyone's benefit. Please feel free to
take this to completion if someone has a better understanding of what
the desired outstanding changes are.

Regards,
Suhail

Omar Bassam (1):
gnu: Add jpm package.

Suhail (1):
gnu: Improve user-experience for jpm.

gnu/packages/lisp.scm | 91 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 91 insertions(+)


base-commit: 9d1b97d7a4ab9c0dbd5808e7859d52cff338f377
--
2.47.0
S
S
Suhail Singh wrote on 5 Nov 18:13 +0100
Re: bug#72925: Adding JPM package for Janet
(name . Ludovic Courtès)(address . ludo@gnu.org)
877c9hr4d1.fsf_-_@gmail.com
Ludo’ (or anyone else with sufficient experience),

Suhail Singh <suhailsingh247@gmail.com> writes:

Toggle quote (34 lines)
>> I suppose JPM shells out to GCC to compiler Janet (or C?) code, right?
>>
>> I’d recommend adding ‘gcc’, ‘glibc’, ‘binutils’, and ‘ld-wrapper’ to
>> ‘inputs’; that’d less us avoid the ‘gcc-toolchain’ dance.
>
> It seems "ld-wrapper" requires (gnu packages commencement) and this
> results in doing the lazy dereference similar to gcc-toolchain above.
> Am I doing something wrong? If not, is the guidance still to add
> "ld-wrapper" to inputs?
>
>> Then in, the phase above, make sure to ‘search-input-file’ rather than
>> direct references to these variables.
>
> Hmm just to be clear, instead of:
>
> #+begin_src scheme
> `("C_INCLUDE_PATH" ":" prefix
> (,(string-append gcc-toolchain "/include")))
> #+end_src
>
>
> What we want is something like:
>
> #+begin_src scheme
> `("C_INCLUDE_PATH" ":" prefix
> (,(search-input-file inputs "/include")))
> #+end_src
>
> Is my understanding correct?
>
> If so, adding "gcc", "glibc", "binutils", and "ld-wrapper" seems
> insufficient to make that work. The search-input-file for "/include"
> results in a "&search-error" when building the package.

Could you please clarify the above? Is v13 I sent good enough? If not,
could someone provide guidance on what's left to do?

Regards,
--
Suhail
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72925@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72925
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch