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

[Suhail Singh <suhailsingh247@gmail.com>]

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