[bug#72925] Adding JPM package for Janet

["Suhail Singh" <suhailsingh247@gmail.com>]

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