Message ID | 4e623d9571ff648ae1d1c6ffb8f9d73c421a5c10.1727683810.git.omar.bassam88@gmail.com |
---|---|
State | New |
Headers | show |
Series | [bug#72925,v3] adding jpm package | expand |
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.
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 >
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.
(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/
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 >
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?
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 >
> > 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/
> > 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/
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.
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.
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 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.
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
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
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 >
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 >> >
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 >>> >>
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.
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")