[bug#72925] Adding JPM package for Janet

[bug#72925] Adding JPM package for Janet

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 3985 bytes --]

From 14fd8cafaebc27a00a4b198abe8e3759583c56b5 Mon Sep 17 00:00:00 2001
Message-ID: <
14fd8cafaebc27a00a4b198abe8e3759583c56b5.1725179146.git.omar.bassam88@gmail.com
>
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(+)

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 #2: Type: text/html, Size: 5528 bytes --]

[bug#72925] [PATCH] adding jpm package

[Omar Bassam]

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..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

[bug#72925] [PATCH] adding jpm package

[Omar Bassam]

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
--- 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

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

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

[bug#72925] Adding JPM package for Janet

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

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:

> 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 #2: Type: text/html, Size: 3129 bytes --]

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

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

> 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

> 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.

> +                    (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

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

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

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

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

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?

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.

> +    (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

[bug#72925] [PATCH v5] gnu: add jpm package

[Omar Bassam]

* gnu/packages/lisp.scm (jpm): New Variable

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

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

[bug#72925] [PATCH v6] gnu: add jpm package

[Omar Bassam]

* gnu/packages/lisp.scm (jpm): New Variable

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

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

[bug#72925] [PATCH v7] gnu: add jpm package

[Omar Bassam]

* gnu/packages/lisp.scm (jpm): New Variable

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

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

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

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:

> 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.


> 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.


> > +    (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 #2: Type: text/html, Size: 6735 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

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.

> 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?

> 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

[bug#72925] [PATCH v3] adding jpm package

[jgart via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

(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:

https://nix.dev/guides/recipes/python-environment.html

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

https://whereis.xn--q9jyb4c/

[-- Attachment #2: Type: text/html, Size: 1047 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

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:

> 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.


> > 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.



> > 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.

> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 3270 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

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).

> 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?

-- 
Suhail

Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)

[Suhail Singh]

Moving the discussion to guix-devel.

"jgart" <jgart@dismail.de> writes:

> 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:
>
> https://nix.dev/guides/recipes/python-environment.html

I believe such guides would be quite helpful.  Perhaps Guix Cookbook
would be the appropriate place for it?

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

As someone curious about JPM, such a guide would be of practical
interest to me.

-- 
Suhail

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 4771 bytes --]

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

> 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).


>
> > 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.


> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 6244 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[jgart via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

> 
> 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.

https://whereis.xn--q9jyb4c/

[-- Attachment #2: Type: text/html, Size: 610 bytes --]

Re: Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

Hi jgart,
I am kind of new to Guix and I am struggling to find resources forlanguage
specific recipes like you mentioned.
I started a project https://lisp-spectrum.org/ where I try to document my
struggles with the Lisp Ecosystemin general (Guix included).
For every Lisp, I try to include a guix manifest to make the instructions
reproducible and I plan to add guides
on how to work with guix on many levels (OS, home and shell) for each
language.

I'm only doing this project for Lisp dialects for now, but I can definitely
see the benefit of having the same thing for other languages as well.


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

> Moving the discussion to guix-devel.
>
> "jgart" <jgart@dismail.de> writes:
>
> > 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:
> >
> > https://nix.dev/guides/recipes/python-environment.html
>
> I believe such guides would be quite helpful.  Perhaps Guix Cookbook
> would be the appropriate place for it?
>
> > would be cool to document the expected workflow for a Guix user using
> > jpm and guix to develop on janet software, for example.
>
> As someone curious about JPM, such a guide would be of practical
> interest to me.
>
> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 2134 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[jgart via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

> 
> 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

https://whereis.xn--q9jyb4c/

[-- Attachment #2: Type: text/html, Size: 1259 bytes --]

Re: Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)

[jgart]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

October 2, 2024 at 3:32 PM, "Omar Bassam" <omar.bassam88@gmail.com mailto:omar.bassam88@gmail.com?to=%22Omar%20Bassam%22%20%3Comar.bassam88%40gmail.com%3E > wrote:



> 
> Hi jgart, 
> I am kind of new to Guix and I am struggling to find resources forlanguage specific recipes like you mentioned. 
> I started a project https://lisp-spectrum.org/ where I try to document my struggles with the Lisp Ecosystemin general (Guix included). 
> For every Lisp, I try to include a guix manifest to make the instructions reproducible and I plan to add guides 
> on how to work with guix on many levels (OS, home and shell) for each language.
> 
> I'm only doing this project for Lisp dialects for now, but I can definitely see the benefit of having the same thing for other languages as well.
> 
Thanks! I'll read your website soon. Great idea!!!

This is one random blog post I know about that discusses a development workflow for Guix:

https://dthompson.us/posts/guix-for-development.html

Have you read that one? Might be relevant.

all best,

jgart

https://whereis.xn--q9jyb4c/

[-- Attachment #2: Type: text/html, Size: 1771 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

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

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

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

> 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 #2: Type: text/html, Size: 3228 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

Omar Bassam <omar.bassam88@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.  I was hoping to get some understanding as to why it
doesn't work as expected, however.

> 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.

> 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?

> 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

[bug#72925] [PATCH v3] adding jpm package

[Suhail Singh]

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.

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

Re: Language-specific guides for using "guix shell"

[indieterminacy]

On 2024-10-02 20:32, Omar Bassam wrote:
> Hi jgart,
> 
> I am kind of new to Guix and I am struggling to find resources
> forlanguage specific recipes like you mentioned.
> 
> I started a project https://lisp-spectrum.org/ where I try to document
> my struggles with the Lisp Ecosystemin general (Guix included).
> 

Cool!

Its worth pointing out the Lisp dialect, TXR
https://www.nongnu.org/txr/txr-lisp.html

FWIW, here are some of my notes:
https://git.sr.ht/~indieterminacy/?search=3q+txr


> For every Lisp, I try to include a guix manifest to make the
> instructions reproducible and I plan to add guides
> 
> on how to work with guix on many levels (OS, home and shell) for each
> language.
> 
> I'm only doing this project for Lisp dialects for now, but I can
> definitely see the benefit of having the same thing for other
> languages as well.
> 
> On Wed, 2 Oct 2024 at 23:20, Suhail Singh <suhailsingh247@gmail.com>
> wrote:
> 
>> Moving the discussion to guix-devel.
>> 
>> "jgart" <jgart@dismail.de> writes:
>> 
>>> 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:
>>> 
>>> https://nix.dev/guides/recipes/python-environment.html
>> 
>> I believe such guides would be quite helpful.  Perhaps Guix Cookbook
>> would be the appropriate place for it?
>> 
>>> would be cool to document the expected workflow for a Guix user
>> using
>>> jpm and guix to develop on janet software, for example.
>> 
>> As someone curious about JPM, such a guide would be of practical
>> interest to me.
>> 
>> --
>> Suhail

Happy hacking!


Jonathan

Re: Language-specific guides for using "guix shell"

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

Hi Jonathan,


On Thu, 3 Oct 2024 at 06:43, indieterminacy <indieterminacy@libre.brussels>
wrote:

> On 2024-10-02 20:32, Omar Bassam wrote:
> > Hi jgart,
> >
> > I am kind of new to Guix and I am struggling to find resources
> > forlanguage specific recipes like you mentioned.
> >
> > I started a project https://lisp-spectrum.org/ where I try to document
> > my struggles with the Lisp Ecosystemin general (Guix included).
> >
>
> Cool!
>
> Its worth pointing out the Lisp dialect, TXR
> https://www.nongnu.org/txr/txr-lisp.html
>
> FWIW, here are some of my notes:
> https://git.sr.ht/~indieterminacy/?search=3q+txr
>
>
WOW, I've never heard of such a project. I didn't know that it's possible
to combine Lisp-1 and Lisp-2 in one implementation.
It looks like a very unique dialect with some unconventional ideas that one
can learn from.
Would you be interested in adding some notes about this dialect in the
lisp-spectrum project?


> > For every Lisp, I try to include a guix manifest to make the
> > instructions reproducible and I plan to add guides
> >
> > on how to work with guix on many levels (OS, home and shell) for each
> > language.
> >
> > I'm only doing this project for Lisp dialects for now, but I can
> > definitely see the benefit of having the same thing for other
> > languages as well.
> >
> > On Wed, 2 Oct 2024 at 23:20, Suhail Singh <suhailsingh247@gmail.com>
> > wrote:
> >
> >> Moving the discussion to guix-devel.
> >>
> >> "jgart" <jgart@dismail.de> writes:
> >>
> >>> 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:
> >>>
> >>> https://nix.dev/guides/recipes/python-environment.html
> >>
> >> I believe such guides would be quite helpful.  Perhaps Guix Cookbook
> >> would be the appropriate place for it?
> >>
> >>> would be cool to document the expected workflow for a Guix user
> >> using
> >>> jpm and guix to develop on janet software, for example.
> >>
> >> As someone curious about JPM, such a guide would be of practical
> >> interest to me.
> >>
> >> --
> >> Suhail
>
> Happy hacking!
>
>
> Jonathan
>

[-- Attachment #2: Type: text/html, Size: 3679 bytes --]

[bug#72925] [PATCH v3] adding jpm package

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

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:

> 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:
> - 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
> understand where I may have erred in the analysis above.
>
> --
> Suhail
>

Thanks,
Omar

[-- Attachment #2: Type: text/html, Size: 2800 bytes --]

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

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

[bug#72925] Adding JPM package for Janet

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 4129 bytes --]

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 #2: Type: text/html, Size: 5346 bytes --]

[bug#72925] Adding JPM package for Janet

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 4400 bytes --]

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 #2: Type: text/html, Size: 5795 bytes --]

[bug#72925] [PATCH v7] gnu: add jpm package

[Omar Bassam]

* gnu/packages/lisp.scm (jpm): New Variable

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

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

[bug#72925] [PATCH v8] gnu: add jpm package

[Omar Bassam]

* gnu/packages/lisp.scm (jpm): New Variable

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

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

[bug#72925] Adding JPM package for Janet

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 4913 bytes --]

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:

> 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 #2: Type: text/html, Size: 6661 bytes --]

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

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

> I just submitted a new path v8. I tested in a pure container shell

Thank you.

> 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
<https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024> for
details on how to add the reviewed-looks-good usertag.

-- 
Suhail

[bug#72925] [PATCH v9] gnu: Add jpm.

[Suhail Singh]

* 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(+)

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

[bug#72925] [PATCH v8] gnu: add jpm package

[Suhail Singh]

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

> +             (url "https://github.com/janet-lang/jpm.git")

The URL redirects to <https://github.com/janet-lang/jpm>.

> +                         (("\"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

> +                         (("\"c++\"")

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

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

Can be similarly simplified.  As well for others.

> +    (inputs (list bash-minimal janet))

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

> +    (propagated-inputs (list janet
> +                             coreutils

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

> +                             git
> +                             curl
> +                             nss-certs

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

> +                             ;; 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.).

> +    (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
<https://janet-lang.org/docs/jpm.html>.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

* 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)
   #: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

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

Suhail Singh <suhailsingh247@gmail.com> writes:

>> +                             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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

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.


> * 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?

>    #: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?

> +    ;; 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?

> +    ;;
> +    ;; 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.

> +    (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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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 :)

>> +    ;; 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.

>> +    ;; 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/>.

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.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Hi Suhail,

Sorry, I have more questions.

> 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? 

>>> +    ;; 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.

>>> +    ;; 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.

> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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?

>>>> +    ;; 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.

> 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.

>>> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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.

>>>>> +    ;; 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.

>
> 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.

>>>> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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.

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.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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.

>
> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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.

> 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

[bug#72925] [PATCH v11] gnu: Add jpm package.

[Omar Bassam]

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

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

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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Hi Suhail,
I just sent v11 addressing your comments.

> 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.

>> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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.

> 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.

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

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

Suhail Singh <suhailsingh247@gmail.com> writes:

>> 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.

> 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

[bug#72925] [PATCH v12 0/2] gnu: Add jpm package.

[Suhail Singh]

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

[bug#72925] [PATCH v12 1/2] gnu: Add jpm package.

[Suhail Singh]

* 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(+)

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

[bug#72925] [PATCH v12 2/2] gnu: Improve user-experience for jpm.

[Suhail Singh]

* 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(-)

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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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.

>> 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.

> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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.

> I am still not sure if I fully understood your C paths cocern correctly.

You may see v12 if curious.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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. 

>
>> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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.

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.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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.

>
> 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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

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:

> 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 #2: Type: text/html, Size: 1078 bytes --]

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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".

> and ready to be merged?

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

> or do we need something else?

See above.

-- 
Suhail

[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

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

> 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.


> > 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?

> or do we need something else?
>
> See above.
>
> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 1470 bytes --]

[bug#72925] [PATCH v10] gnu: Add jpm.

[Suhail Singh]

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

> 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

[bug#72925] Adding JPM package for Janet

[Ludovic Courtès]

Hi,

Suhail Singh <suhailsingh247@gmail.com> skribis:

> * 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…

> +    (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’.

[bug#72925] Adding JPM package for Janet

[Ludovic Courtès]

Suhail Singh <suhailsingh247@gmail.com> skribis:

> * 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

[...]

> +                         (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’.

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

Ludovic Courtès <ludo@gnu.org> writes:

>> +                         (("\"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

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

Ludovic Courtès <ludo@gnu.org> writes:

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

Yes.

> 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.

> 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

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

Ludovic Courtès <ludo@gnu.org> writes:

>> +                         (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?

> 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

[bug#72925] [PATCH v13 0/2] Add jpm.

[Suhail Singh]

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

[bug#72925] [PATCH v13 1/2] gnu: Add jpm package.

[Suhail Singh]

* 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(+)

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

[bug#72925] [PATCH v13 2/2] gnu: Improve user-experience for jpm.

[Suhail Singh]

* 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(-)

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

Re: Language-specific guides for using "guix shell"

[Ludovic Courtès]

Hi,

Suhail Singh <suhailsingh247@gmail.com> skribis:

> "jgart" <jgart@dismail.de> writes:
>
>> 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:
>>
>> https://nix.dev/guides/recipes/python-environment.html
>
> I believe such guides would be quite helpful.  Perhaps Guix Cookbook
> would be the appropriate place for it?

I agree it’d be useful, and I think the Cookbook is indeed a good place
for that.

Ludo’.

[bug#72925] Adding JPM package for Janet

[Suhail Singh]

Ludo’ (or anyone else with sufficient experience),

Suhail Singh <suhailsingh247@gmail.com> writes:

>> 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