unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
* `--run=simple` error ?
@ 2019-02-21 15:22 zimoun
  2019-02-21 15:40 ` Ricardo Wurmus
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-21 15:22 UTC (permalink / raw)
  To: gwl-devel

Hi,

I am not able to run any workflow any more.
Well, I use Guix on a foreign distro so maybe my config is wrong;
especially about the Guile modules.

My variables are:

export PATH="$HOME/.config/guix/current/bin:$HOME/.guix-profile/bin:$HOME/.guix-profile/sbin${PATH:+:}$PATH"
export GUILE_LOAD_PATH="$HOME/.guix-profile/share/guile/site/2.2${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
export GUILE_LOAD_COMPILED_PATH="$HOME/.guix-profile/lib/guile/2.2/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"


Then the environment is set with:

guix environment  --ad-hoc autoconf automake pkg-config texlive-tiny
guile guile-commonmark guile-syntax-highlight guile-wisp


Well, the compilation seems to work:

 ./bootstrap
 ./configure
  make


However, `make check` fails on tests/sugar.scm.


And finally, I am not able to run any workflow:

GUIX_WORKFLOW_PATH=./doc/examples/ ./pre-inst-env guix workflow -l

lists simple etc. But:

GUIX_WORKFLOW_PATH=./doc/examples/ ./pre-inst-env guix workflow -r simple

fails with the backtrace (below).


Hum? Elsewhere Ricardo mentions issue with Guile versions.

If I understand well, the issue should come from that GWL is compiled
with a version of Guile and this Guile version is incompatible with
the Guile version used to compile Guix with the `guix pull'. Right?


The ./configure says:

[...]
configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... no
checking for guile2.2... no
checking for guile-2... no
checking for guile2... no
checking for guile...
/gnu/store/xd3p0nq4xh59wnvsadm2gf8xclbbwv4h-profile/bin/guile
checking for Guile version >= 2.2... 2.2.4
checking for guild...
/gnu/store/xd3p0nq4xh59wnvsadm2gf8xclbbwv4h-profile/bin/guild
checking for guile-config...
/gnu/store/xd3p0nq4xh59wnvsadm2gf8xclbbwv4h-profile/bin/guile-config
[...]


Then
  /gnu/store/xd3p0nq4xh59wnvsadm2gf8xclbbwv4h-profile/bin/guile
points to
  /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile


And
   find /gnu/ -name "guile" -type f -print
/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
/gnu/store/1fl9vk8fpafkws4qyy25vcdfpybxyh1k-guile-2.0.14/bin/guile

When I `guix pull`, I track which Guile is used.
Surprise surprise... it is not the same. :-)
It is the one in /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4.



Well, the questions are:

 - Does the issue come from that? This subtle difference?
 - How can I fix the issue? Either recompile Guix with the correct
Guile. Either compile GWL with the other Guix version.


Thank you in advance for your lights.


All the best,
simon

--

Backtrace:
           9 (primitive-load "/home/simon/.config/guix/current/bin/g…")
In guix/ui.scm:
  1639:12  8 (run-guix-command _ . _)
In guix/scripts/workflow.scm:
   158:24  7 (guix-workflow . _)
In gwl/workflows.scm:
    223:4  6 (workflow-run #<workflow simple> #<process-engine simp…> …)
In gwl/cache.scm:
    77:16  5 (make-process->cache-prefix _ _ _)
     72:7  4 (workflow->data-hashes #<workflow simple> (#<proces…> …) …)
In srfi/srfi-1.scm:
   466:18  3 (fold #<procedure kons (process acc)> () (#<process …> …))
In gwl/cache.scm:
    56:19  2 (kons #<process greet> ())
In gwl/processes.scm:
    315:2  1 (derivation->script #<procedure 40a6870 at gwl/process…> …)
In unknown file:
           0 (_ #<store-connection 256.99 410df00>)

ERROR: Wrong type to apply: #<syntax-transformer nix-server-version>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-21 15:22 `--run=simple` error ? zimoun
@ 2019-02-21 15:40 ` Ricardo Wurmus
  2019-02-22 16:22   ` zimoun
  0 siblings, 1 reply; 16+ messages in thread
From: Ricardo Wurmus @ 2019-02-21 15:40 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


zimoun <zimon.toutoune@gmail.com> writes:

> My variables are:
>
> export PATH="$HOME/.config/guix/current/bin:$HOME/.guix-profile/bin:$HOME/.guix-profile/sbin${PATH:+:}$PATH"
> export GUILE_LOAD_PATH="$HOME/.guix-profile/share/guile/site/2.2${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
> export GUILE_LOAD_COMPILED_PATH="$HOME/.guix-profile/lib/guile/2.2/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"

I think you should unset GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH as
you’re working in an environment anyway.

This error:

--8<---------------cut here---------------start------------->8---
Backtrace:
           9 (primitive-load "/home/simon/.config/guix/current/bin/g…")
In guix/ui.scm:
  1639:12  8 (run-guix-command _ . _)
In guix/scripts/workflow.scm:
   158:24  7 (guix-workflow . _)
In gwl/workflows.scm:
    223:4  6 (workflow-run #<workflow simple> #<process-engine simp…> …)
In gwl/cache.scm:
    77:16  5 (make-process->cache-prefix _ _ _)
     72:7  4 (workflow->data-hashes #<workflow simple> (#<proces…> …) …)
In srfi/srfi-1.scm:
   466:18  3 (fold #<procedure kons (process acc)> () (#<process …> …))
In gwl/cache.scm:
    56:19  2 (kons #<process greet> ())
In gwl/processes.scm:
    315:2  1 (derivation->script #<procedure 40a6870 at gwl/process…> …)
In unknown file:
           0 (_ #<store-connection 256.99 410df00>)

ERROR: Wrong type to apply: #<syntax-transformer nix-server-version>

--8<---------------cut here---------------end--------------->8---

… that’s likely due to ABI change in Guix.  Have you cleared all .go
files?  Do you still get this when GUILE_LOAD_COMPILED_PATH and
GUILE_LOAD_PATH are unset?

~~ Ricardo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-21 15:40 ` Ricardo Wurmus
@ 2019-02-22 16:22   ` zimoun
  2019-02-22 16:33     ` Pjotr Prins
  2019-02-22 16:35     ` Ricardo Wurmus
  0 siblings, 2 replies; 16+ messages in thread
From: zimoun @ 2019-02-22 16:22 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

Thank you for your help.

On Thu, 21 Feb 2019 at 16:40, Ricardo Wurmus <rekado@elephly.net> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

> I think you should unset GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH as
> you’re working in an environment anyway.

Ok.
I have unset and also tried with --pure and --container.
No effect.

> … that’s likely due to ABI change in Guix.  Have you cleared all .go
> files?  Do you still get this when GUILE_LOAD_COMPILED_PATH and
> GUILE_LOAD_PATH are unset?

All .go where ?
In the GWL checkout, yes. It was the first thing I tried. :-)
Otherwise, no I have not cleared any .go files. Which ones I need to clear?

From my understanding, the issue comes from: GWL compiles with
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile

But GWL needs guix modules and these modules have been compiled with
another Guile, I guess.
/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile

And the ABI issue perhaps comes from that.

So, I removed the Guix modules installed (e.g. with guix environment
gwl) and then I reinstalled them. Now, it seems to work. \o/


Well, if I understand well, because I am running Guix on a foreign
distro, there is a "big dance" with the Guix modules. Somehow, it is
similar with one emacs-guix issue on non full GuixSystem explained in
the second part of this message [1].
You proposed something here [2] but to be honest I have not tried yet
because my mind is not clear about all that.

If it is the similar issue than the emacs-guix one, we need to propose
or document the issue because it is tricky.

[1] https://lists.gnu.org/archive/html/help-guix/2019-01/msg00020.html
[2] https://lists.gnu.org/archive/html/help-guix/2019-01/msg00041.html


Well, now I can play again with the GWL. ;-)

Thank you again.

All the best,
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:22   ` zimoun
@ 2019-02-22 16:33     ` Pjotr Prins
  2019-02-22 16:48       ` zimoun
  2019-02-22 16:35     ` Ricardo Wurmus
  1 sibling, 1 reply; 16+ messages in thread
From: Pjotr Prins @ 2019-02-22 16:33 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel

On Fri, Feb 22, 2019 at 05:22:39PM +0100, zimoun wrote:
> Well, if I understand well, because I am running Guix on a foreign
> distro, there is a "big dance" with the Guix modules. Somehow, it is
> similar with one emacs-guix issue on non full GuixSystem explained in
> the second part of this message

Yes, it can be hard. Best is to systematically rule out problems.
Containers are preferred by me because there is no chance of a mixup.

Pj.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:22   ` zimoun
  2019-02-22 16:33     ` Pjotr Prins
@ 2019-02-22 16:35     ` Ricardo Wurmus
  2019-02-22 16:55       ` zimoun
  1 sibling, 1 reply; 16+ messages in thread
From: Ricardo Wurmus @ 2019-02-22 16:35 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


zimoun <zimon.toutoune@gmail.com> writes:

>> … that’s likely due to ABI change in Guix.  Have you cleared all .go
>> files?  Do you still get this when GUILE_LOAD_COMPILED_PATH and
>> GUILE_LOAD_PATH are unset?
>
> All .go where ?
> In the GWL checkout, yes. It was the first thing I tried. :-)
> Otherwise, no I have not cleared any .go files. Which ones I need to clear?
>
> From my understanding, the issue comes from: GWL compiles with
> /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
>
> But GWL needs guix modules and these modules have been compiled with
> another Guile, I guess.
> /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile
>
> And the ABI issue perhaps comes from that.

No, the version of Guile is not at fault here.  It’s about the version
of Guix.

(The GWL builds with Guix as an input.)

I’m not sure what’s the best way to install the GWL, to be honest.
Should it be a mere channel that extends the *current* Guix?  If it is
built with Guix then it refers to an older version of Guix (namely the
older version that is available through Guix itself), so that’s not
actually desirable.

I think it should work with “guix pull” to stay current and ensure that
it has access to the same packages that a user would see on the command
line.  Currently, this only works through a channel.  I don’t really
like that, though.

--
Ricardo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:33     ` Pjotr Prins
@ 2019-02-22 16:48       ` zimoun
  2019-02-22 16:57         ` Pjotr Prins
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-22 16:48 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: gwl-devel

Hi Pjotr,

On Fri, 22 Feb 2019 at 17:33, Pjotr Prins <pjotr2019@thebird.nl> wrote:
>
> Yes, it can be hard. Best is to systematically rule out problems.
> Containers are preferred by me because there is no chance of a mixup.

Yes but when speaking about Guix modules, one wants the most
up-to-date (i.e. from guix pull) which is not necessary the case with
container (i.e. from guix package -i guix).

From my understanding, there is a real "issue" for all the packages
that depends on the package guix. For example emacs-guix, gwl that I
am aware of.

Cheers
--
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:35     ` Ricardo Wurmus
@ 2019-02-22 16:55       ` zimoun
  2019-02-22 17:04         ` Ricardo Wurmus
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-22 16:55 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

On Fri, 22 Feb 2019 at 17:35, Ricardo Wurmus <rekado@elephly.net> wrote:

> No, the version of Guile is not at fault here.  It’s about the version
> of Guix.
>
> (The GWL builds with Guix as an input.)

Ok.


> I’m not sure what’s the best way to install the GWL, to be honest.

From my opinion, it is similar than emacs-guix, isn't it?


> Should it be a mere channel that extends the *current* Guix?  If it is
> built with Guix then it refers to an older version of Guix (namely the
> older version that is available through Guix itself), so that’s not
> actually desirable.

I agree.


> I think it should work with “guix pull” to stay current and ensure that
> it has access to the same packages that a user would see on the command
> line.  Currently, this only works through a channel.  I don’t really
> like that, though.

You have proposed something like: “~/.config/guix/current/bin/guix repl”

Why do you not like the channel and kind of inferior solution?


All the best,
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:48       ` zimoun
@ 2019-02-22 16:57         ` Pjotr Prins
  2019-02-22 21:05           ` zimoun
  0 siblings, 1 reply; 16+ messages in thread
From: Pjotr Prins @ 2019-02-22 16:57 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel

On Fri, Feb 22, 2019 at 05:48:23PM +0100, zimoun wrote:
> Hi Pjotr,
> 
> On Fri, 22 Feb 2019 at 17:33, Pjotr Prins <pjotr2019@thebird.nl> wrote:
> >
> > Yes, it can be hard. Best is to systematically rule out problems.
> > Containers are preferred by me because there is no chance of a mixup.
> 
> Yes but when speaking about Guix modules, one wants the most
> up-to-date (i.e. from guix pull) which is not necessary the case with
> container (i.e. from guix package -i guix).
> 
> From my understanding, there is a real "issue" for all the packages
> that depends on the package guix. For example emacs-guix, gwl that I
> am aware of.

You can run a container in a freshly compiled source tree. I do that
all the time. I don't normally use guix pull. Example using a D compiler

  ~/guix-master/pre-inst-env guix environment -C guix --ad-hoc ldc clang llvm unzip gdb ncurses vim git make cmake which less tzdata binutils
  rm -rf CMakeFiles CMakeCache.txt
  cmake .
  make clean
  make -j 24

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:55       ` zimoun
@ 2019-02-22 17:04         ` Ricardo Wurmus
  2019-02-22 21:10           ` zimoun
  0 siblings, 1 reply; 16+ messages in thread
From: Ricardo Wurmus @ 2019-02-22 17:04 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel, ludo

Hi Simon,

>> I think it should work with “guix pull” to stay current and ensure that
>> it has access to the same packages that a user would see on the command
>> line.  Currently, this only works through a channel.  I don’t really
>> like that, though.
>
> You have proposed something like: “~/.config/guix/current/bin/guix repl”
>
> Why do you not like the channel and kind of inferior solution?

I want the GWL to be a proper package one can install, with
documentation and all that.  Installing it as a channel doesn’t have the
same feel.  It would be compiled afresh on every update and that seems
wrong to me.

Channels are primarily for extending the package collection, not to
provide new Guix commands.

While the GWL does depend on Guix as a library it does not directly
depend on the Guix package collection.  We want that to be whatever the
user happens to use.  I feel that maybe there really ought to be a
Guix library that’s separate from the package collection…

Don’t know.

--
Ricardo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 16:57         ` Pjotr Prins
@ 2019-02-22 21:05           ` zimoun
  2019-02-22 21:18             ` Pjotr Prins
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-22 21:05 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: gwl-devel

Hi Pjotr,

> You can run a container in a freshly compiled source tree. I do that
> all the time. I don't normally use guix pull. Example using a D compiler
>
>   ~/guix-master/pre-inst-env guix environment -C guix --ad-hoc ldc clang llvm unzip gdb ncurses vim git make cmake which less tzdata binutils
>   rm -rf CMakeFiles CMakeCache.txt
>   cmake .
>   make clean
>   make -j 24

Thank you for the trick.
I will use more containers. ;-)

However, the issue is now how to ./configure Guix and one also needs
to turn on container support (root privileges).
And say it is maybe not the most friendly. :-) I mean it is the hacker
solution (and yes they know how to choose their friend ;-)


Well, even I am still confused.

Which guix modules are going to the container ?
    a) the ones from the package guix in the checkout
or b) the ones of the checkout itself.
And is it the guix modules or only its dependencies? (guile, autotools, etc.)

And idem if you run instead:
~/guix-master/pre-inst-env guix environment -C gwl --ad-hoc some other tools
or any other package that depends on Guix.


Cheers,
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 17:04         ` Ricardo Wurmus
@ 2019-02-22 21:10           ` zimoun
  2019-02-22 22:54             ` Ricardo Wurmus
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-22 21:10 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel, Ludovic Courtès

Hi RIcardo,

On Fri, 22 Feb 2019 at 18:05, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> While the GWL does depend on Guix as a library it does not directly
> depend on the Guix package collection.  We want that to be whatever the
> user happens to use.  I feel that maybe there really ought to be a
> Guix library that’s separate from the package collection…

I agree that there is something unclear with the Guix library on non
full GuixSystem.
From my understanding, it is the same issue for emacs-guix, isn't it?


Cheers,
--
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 21:05           ` zimoun
@ 2019-02-22 21:18             ` Pjotr Prins
  2019-02-24 11:40               ` zimoun
  0 siblings, 1 reply; 16+ messages in thread
From: Pjotr Prins @ 2019-02-22 21:18 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel

On Fri, Feb 22, 2019 at 10:05:45PM +0100, zimoun wrote:
> Hi Pjotr,
> 
> > You can run a container in a freshly compiled source tree. I do that
> > all the time. I don't normally use guix pull. Example using a D compiler
> >
> >   ~/guix-master/pre-inst-env guix environment -C guix --ad-hoc ldc clang llvm unzip gdb ncurses vim git make cmake which less tzdata binutils
> >   rm -rf CMakeFiles CMakeCache.txt
> >   cmake .
> >   make clean
> >   make -j 24
> 
> Thank you for the trick.
> I will use more containers. ;-)
> 
> However, the issue is now how to ./configure Guix and one also needs
> to turn on container support (root privileges).

Yes. Fair point. Works on machines that allow that though and it is
good for resolving issues.

> And say it is maybe not the most friendly. :-) I mean it is the hacker
> solution (and yes they know how to choose their friend ;-)
> 
> 
> Well, even I am still confused.
> 
> Which guix modules are going to the container ?
>     a) the ones from the package guix in the checkout
> or b) the ones of the checkout itself.

guix environment -C guix 

pulls in everything you need to build guix itself.

> And is it the guix modules or only its dependencies? (guile, autotools, etc.)

try it, you can check. Also read 

https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix---the-bullet-proof-way

> And idem if you run instead:
> ~/guix-master/pre-inst-env guix environment -C gwl --ad-hoc some other tools
> or any other package that depends on Guix.

Just check what is in the /gnu/store.

> 
> Cheers,
> simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 21:10           ` zimoun
@ 2019-02-22 22:54             ` Ricardo Wurmus
  2019-02-24 11:56               ` zimoun
  0 siblings, 1 reply; 16+ messages in thread
From: Ricardo Wurmus @ 2019-02-22 22:54 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel, Ludovic Courtès


zimoun <zimon.toutoune@gmail.com> writes:

> On Fri, 22 Feb 2019 at 18:05, Ricardo Wurmus <rekado@elephly.net> wrote:
>>
>> While the GWL does depend on Guix as a library it does not directly
>> depend on the Guix package collection.  We want that to be whatever the
>> user happens to use.  I feel that maybe there really ought to be a
>> Guix library that’s separate from the package collection…
>
> I agree that there is something unclear with the Guix library on non
> full GuixSystem.

I think it’s the same problem as on a Guix system.  The Guix we have at
build time is not the same as the Guix at runtime.  For some things this
doesn’t matter (or shouldn’t matter) — like the derivation stuff; for
other things it very much matters — like packages and records used to
describe them.

I don’t know the emacs-guix problem to say if it’s similar.

-- 
Ricardo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 21:18             ` Pjotr Prins
@ 2019-02-24 11:40               ` zimoun
  2019-02-24 12:02                 ` Pjotr Prins
  0 siblings, 1 reply; 16+ messages in thread
From: zimoun @ 2019-02-24 11:40 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: gwl-devel

Hi Pjotr,

On Fri, 22 Feb 2019 at 22:18, Pjotr Prins <pjotr2019@thebird.nl> wrote:
>
> guix environment -C guix
>
> pulls in everything you need to build guix itself.

If I understand well, this sequence:

  cd ~/guix-master
  git checkout <hash>
  cd /path/to/project
  ~/guix-master/pre-inst-env guix environment -C tool --ad-hoc other tools

is nouw somehow equivalent to:

  guix pull --commit=<hash>
  guix environment -C tool --ad-hoc othertools

Right?

> > And is it the guix modules or only its dependencies? (guile, autotools, etc.)
>
> try it, you can check. Also read
>
> https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix---the-bullet-proof-way
>
> > And idem if you run instead:
> > ~/guix-master/pre-inst-env guix environment -C gwl --ad-hoc some other tools
> > or any other package that depends on Guix.


In fact, the question is how to do when a package (gwl) depends on
Guix the library.
Kind of build time vs run time. If I understand well.
It was my initial issue: gwl was built with a version of Guix. Then it
fails at run time because the very Guix version was incompatible.


All the best
--
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-22 22:54             ` Ricardo Wurmus
@ 2019-02-24 11:56               ` zimoun
  0 siblings, 0 replies; 16+ messages in thread
From: zimoun @ 2019-02-24 11:56 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel, Ludovic Courtès

Hi Ricardo,


On Fri, 22 Feb 2019 at 23:55, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> I think it’s the same problem as on a Guix system.  The Guix we have at
> build time is not the same as the Guix at runtime.  For some things this
> doesn’t matter (or shouldn’t matter) — like the derivation stuff; for
> other things it very much matters — like packages and records used to
> describe them.
>
> I don’t know the emacs-guix problem to say if it’s similar.

I let you judging :-)

See the Alex Kost's explanations here:
https://github.com/alezost/guix.el/issues/28#issuecomment-448682215

Or it was recently discussed in the help-guix thread here :
https://lists.gnu.org/archive/html/help-guix/2019-01/msg00029.html

Where the interesting messages are:
 - yours ;-)
https://lists.gnu.org/archive/html/help-guix/2019-01/msg00041.html
 - Alex's one:
https://lists.gnu.org/archive/html/help-guix/2019-01/msg00051.html
 - Ludo's one:
https://lists.gnu.org/archive/html/help-guix/2019-01/msg00125.html


Cheers
--
simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: `--run=simple` error ?
  2019-02-24 11:40               ` zimoun
@ 2019-02-24 12:02                 ` Pjotr Prins
  0 siblings, 0 replies; 16+ messages in thread
From: Pjotr Prins @ 2019-02-24 12:02 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel

On Sun, Feb 24, 2019 at 12:40:13PM +0100, zimoun wrote:
> Hi Pjotr,
> 
> On Fri, 22 Feb 2019 at 22:18, Pjotr Prins <pjotr2019@thebird.nl> wrote:
> >
> > guix environment -C guix
> >
> > pulls in everything you need to build guix itself.
> 
> If I understand well, this sequence:
> 
>   cd ~/guix-master
>   git checkout <hash>
>   cd /path/to/project
>   ~/guix-master/pre-inst-env guix environment -C tool --ad-hoc other tools
> 
> is nouw somehow equivalent to:
> 
>   guix pull --commit=<hash>
>   guix environment -C tool --ad-hoc othertools

Guix pull also pulls in its build environment.

> Right?
> 
> > > And is it the guix modules or only its dependencies? (guile, autotools, etc.)
> >
> > try it, you can check. Also read
> >
> > https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix---the-bullet-proof-way
> >
> > > And idem if you run instead:
> > > ~/guix-master/pre-inst-env guix environment -C gwl --ad-hoc some other tools
> > > or any other package that depends on Guix.
> 
> 
> In fact, the question is how to do when a package (gwl) depends on
> Guix the library.
> Kind of build time vs run time. If I understand well.
> It was my initial issue: gwl was built with a version of Guix. Then it
> fails at run time because the very Guix version was incompatible.

Yeah. You have to get the PATHs right for the different purposes.

Pj.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2019-02-24 12:09 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-21 15:22 `--run=simple` error ? zimoun
2019-02-21 15:40 ` Ricardo Wurmus
2019-02-22 16:22   ` zimoun
2019-02-22 16:33     ` Pjotr Prins
2019-02-22 16:48       ` zimoun
2019-02-22 16:57         ` Pjotr Prins
2019-02-22 21:05           ` zimoun
2019-02-22 21:18             ` Pjotr Prins
2019-02-24 11:40               ` zimoun
2019-02-24 12:02                 ` Pjotr Prins
2019-02-22 16:35     ` Ricardo Wurmus
2019-02-22 16:55       ` zimoun
2019-02-22 17:04         ` Ricardo Wurmus
2019-02-22 21:10           ` zimoun
2019-02-22 22:54             ` Ricardo Wurmus
2019-02-24 11:56               ` zimoun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).