Jan Wielkiewicz writes:
> I tried both ways - the second works, but the first doesn't.
That would be the "in theory, it would work" part. On further investigation,
source-module-closure has a #:select? keyword argument, which takes a module
name and returns #f if it shouldn't be included in the
Hi!
I tried both ways - the second works, but the first doesn't.
That's what I have in the file - if I didn't miss something, it is the
same as your example:
#:imported-modules (,@(source-module-closure
'((gnu packages jami)
,@%gnu-build-system-modules)))
#:modules ((gnu packages
Hi Julien,
Julien Lepiller skribis:
> I presented the project at JRES yesterday and had lots of questions
> and reactions.
Thanks for the nice talk and for sharing feedback! It’s really great to
see how each one of us approaches it from a different angle, and I think
you chose the right one fo
Hi Konrad,
Konrad Hinsen skribis:
>> If I might, one the best presentation [1] -- that I am aware of -- on
>> this. Sorry in French.
>
> Thanks for the marketing :-)
>
>> [1]
>> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
>> https://aramis.resinfo.org/wiki/l
Hi Ludo,
On Tue, 10 Dec 2019 at 17:19, Ludovic Courtès wrote:
> YOANN P skribis:
> >> As said, it is not a bug of "guix pull" but a bug of the
> >> configuration. Adding the root user to your Dockerfile should fix the
> >> issue you encounter.
> >
> > The fact that guix require $USER to be set
Hi!
Julien Lepiller skribis:
> Could this discussion be saved in the cookbook for instance? I'd like to have
> this kind of discussion on the approach of guix and ideas behind it somewhere
> more accessible than the ML archive. Does it make sense?
I sort of see the cookbook as a very practica
Hi Yoann,
YOANN P skribis:
>> It is similar to Bug#36785 [1].
>
>> As said, it is not a bug of "guix pull" but a bug of the
>> configuration. Adding the root user to your Dockerfile should fix the
>> issue you encounter.
>
> The fact that guix require $USER to be set is IMO a kind of bug and is
zimoun writes:
> If I understand well, the policy is: the packages in the file cran.scm
> cannot import '(gnu packages bioconductor).
Yes. It’s not official policy, but I think we should avoid mutually
recursive module imports when we have a choice.
> In the file cran.scm, for example the pa
Dear all,
FOSDEM is coming early February and not only are we organizing the GNU
Guix days, we also have a devroom with exciting talks on Guile, Guix,
and Mes! See
https://libreplanet.org/wiki/Group:Guix/FOSDEM2020
and
https://fosdem.org/2020/schedule/track/minimalistic_experimental_and_e
Hi,
On Tue, 10 Dec 2019 at 09:41, Ricardo Wurmus wrote:
> > --8<---cut here---start->8---
> > ;; This is a CRAN package, but it uncharacteristically depends on a
> > ;; Bioconductor package
> > --8<---cut here---end--->8---
Wow, thanks for the explanation, it's very enlightening!
This should probably end up in the documentation somewhere. Maybe as
part of the packaging tutorial? Or for the long-due "Advanced Packaging
Tutorial"?
> (define my-procedure-code '(lambda (a b c) ...))
>
> (arguments
> `(#:phases (let
#:modules and #:imported-modules are distinct arguments. #:modules is the
modules that your builder is going to use (as in "they go in a (use-modules
...) form"), while #:imported-modules is the modules that need to be
available
in the build environment. It's complaining at build-time that it can't
zimoun writes:
> 1.
> Currently, the file bioconductor.scm contains 4 packages with
> 'cran-uri' and git blames you. :-)
>
> Well, the 4 commits are:
>
> : a207bca2ad gnu: r-codedepends: Move from cran to bioconductor.
> : 3a0babacdc gnu: Add r-htscluster.
> : 7ed869f796 gnu: Add r-nbpseq.
> :
13 matches
Mail list logo
