* chicken scheme
@ 2016-06-30 19:11 John J Foerch
2016-06-30 21:27 ` Ludovic Courtès
0 siblings, 1 reply; 14+ messages in thread
From: John J Foerch @ 2016-06-30 19:11 UTC (permalink / raw)
To: help-guix
Hello,
I ran into some problems when installing CHICKEN Scheme on my new GuixSD
system. After installing the chicken package, 'chicken-install' failed
because gcc was not found on the system. In the package definition for
chicken, gcc is listed as a native-input, but from what I understand it
should either be a regular input or a propagated-input, because CHICKEN
uses gcc to compile scheme programs.
I installed gcc separately, and then a test of chicken-install produced
this error:
linux/limits.h: No such file or directory #include <linux/limits.h>
I was testing chicken-install with this command:
$ chicken-install matchable
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-06-30 19:11 chicken scheme John J Foerch
@ 2016-06-30 21:27 ` Ludovic Courtès
2016-06-30 21:43 ` John J Foerch
2016-06-30 22:05 ` John J Foerch
0 siblings, 2 replies; 14+ messages in thread
From: Ludovic Courtès @ 2016-06-30 21:27 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
Hi,
John J Foerch <jjfoerch@earthlink.net> skribis:
> I ran into some problems when installing CHICKEN Scheme on my new GuixSD
> system. After installing the chicken package, 'chicken-install' failed
> because gcc was not found on the system. In the package definition for
> chicken, gcc is listed as a native-input, but from what I understand it
> should either be a regular input or a propagated-input, because CHICKEN
> uses gcc to compile scheme programs.
Good point. Perhaps CHICKEN should keep references to the GCC toolchain
that was used to build it, or propagate it. OTOH, it can in theory use
whatever GCC that it finds in $PATH, and people using the interpreter
don’t need GCC, which would be an argument in favor of the status quo.
Thoughts?
> I installed gcc separately, and then a test of chicken-install produced
> this error:
>
> linux/limits.h: No such file or directory #include <linux/limits.h>
>
> I was testing chicken-install with this command:
>
> $ chicken-install matchable
Could you run:
guix package -r gcc -i gcc-toolchain
and try again?
The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper
around ‘ld’ (it makes sure every library linked against is added to the
RUNPATH.)
Thanks for reporting the issue,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-06-30 21:27 ` Ludovic Courtès
@ 2016-06-30 21:43 ` John J Foerch
2016-07-01 9:36 ` Ludovic Courtès
2016-06-30 22:05 ` John J Foerch
1 sibling, 1 reply; 14+ messages in thread
From: John J Foerch @ 2016-06-30 21:43 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> I ran into some problems when installing CHICKEN Scheme on my new GuixSD
>> system. After installing the chicken package, 'chicken-install' failed
>> because gcc was not found on the system. In the package definition for
>> chicken, gcc is listed as a native-input, but from what I understand it
>> should either be a regular input or a propagated-input, because CHICKEN
>> uses gcc to compile scheme programs.
>
> Good point. Perhaps CHICKEN should keep references to the GCC toolchain
> that was used to build it, or propagate it. OTOH, it can in theory use
> whatever GCC that it finds in $PATH, and people using the interpreter
> don’t need GCC, which would be an argument in favor of the status quo.
>
> Thoughts?
>
>> I installed gcc separately, and then a test of chicken-install produced
>> this error:
>>
>> linux/limits.h: No such file or directory #include <linux/limits.h>
>>
>> I was testing chicken-install with this command:
>>
>> $ chicken-install matchable
>
> Could you run:
>
> guix package -r gcc -i gcc-toolchain
>
> and try again?
>
> The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper
> around ‘ld’ (it makes sure every library linked against is added to the
> RUNPATH.)
>
> Thanks for reporting the issue,
> Ludo’.
Hello Ludovic,
Installing gcc-toolchain helped, and there are no more compilation
errors. Another error came up in trying to install the built files.
Here is my log:
$ chicken-install matchable
retrieving ...
connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
requesting "/henrietta.cgi?name=matchable&mode=default" ...
reading response ...
HTTP/1.1 200 OK
Date: Thu, 30 Jun 2016 21:36:20 GMT
Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
reading chunks ...
reading files ...
./match-simple.scm
./match.scm
./matchable-test.scm
./matchable.meta
./matchable.scm
./matchable.setup
matchable located at /tmp/temp112c.2170/matchable
checking platform for `matchable' ...
checking dependencies for `matchable' ...
install order:
("matchable")
installing matchable:3.6 ...
changing current directory to /tmp/temp112c.2170/matchable
'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup'
'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.scm -j matchable
'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.import.scm
cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system
Error: shell command failed with nonzero exit status 256:
cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
Error: shell command terminated with nonzero exit code
17920
"'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu...
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-06-30 21:27 ` Ludovic Courtès
2016-06-30 21:43 ` John J Foerch
@ 2016-06-30 22:05 ` John J Foerch
2016-07-01 9:39 ` Ludovic Courtès
1 sibling, 1 reply; 14+ messages in thread
From: John J Foerch @ 2016-06-30 22:05 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
>
> Good point. Perhaps CHICKEN should keep references to the GCC toolchain
> that was used to build it, or propagate it. OTOH, it can in theory use
> whatever GCC that it finds in $PATH, and people using the interpreter
> don’t need GCC, which would be an argument in favor of the status quo.
>
> Thoughts?
>
I don't have enough experience with guix to give definite advice on
this, but chicken does present a couple of unique issues. I think that
having gcc available is essential to chicken's purpose, as one is not
likely to only use the interpreter. Installing extensions requires C
compilation, and if one is not installing extensions and not using
chicken's compiler, then one might as well be using any old scheme off
the street ;-)
If the gcc-toolchain were kept in reference (but not in the profile),
that may be enough. The chicken compiler has options (and/or
environment variables) to use another gcc if desired, so people who want
to use another gcc than the one used to build chicken can still do so.
Some chicken extensions install executable programs (for example
hyde). On other OSes they would normally be installed to
/usr/local/bin. Obviously this would be different for guix.
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-06-30 21:43 ` John J Foerch
@ 2016-07-01 9:36 ` Ludovic Courtès
2016-07-01 12:11 ` John J Foerch
0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-07-01 9:36 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
John J Foerch <jjfoerch@earthlink.net> skribis:
> Installing gcc-toolchain helped, and there are no more compilation
> errors. Another error came up in trying to install the built files.
> Here is my log:
>
> $ chicken-install matchable
> retrieving ...
> connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
> requesting "/henrietta.cgi?name=matchable&mode=default" ...
> reading response ...
> HTTP/1.1 200 OK
> Date: Thu, 30 Jun 2016 21:36:20 GMT
> Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/plain
> reading chunks ...
> reading files ...
> ./match-simple.scm
> ./match.scm
> ./matchable-test.scm
> ./matchable.meta
> ./matchable.scm
> ./matchable.setup
> matchable located at /tmp/temp112c.2170/matchable
> checking platform for `matchable' ...
> checking dependencies for `matchable' ...
> install order:
> ("matchable")
> installing matchable:3.6 ...
> changing current directory to /tmp/temp112c.2170/matchable
> '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup'
> '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.scm -j matchable
> '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.import.scm
> cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
> cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system
>
> Error: shell command failed with nonzero exit status 256:
>
> cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
>
>
> Error: shell command terminated with nonzero exit code
> 17920
> "'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu...
I think we need to build CHICKEN such that it uses /var/lib instead of
/gnu/store/…-chicken/var/lib (the latter is immutable.) I suppose
that’s how it works on other distros, right? (With this approach only
root can install software, though.)
Do you know how to make this change?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-06-30 22:05 ` John J Foerch
@ 2016-07-01 9:39 ` Ludovic Courtès
2016-07-01 12:16 ` John J Foerch
0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-07-01 9:39 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
John J Foerch <jjfoerch@earthlink.net> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
> I don't have enough experience with guix to give definite advice on
> this, but chicken does present a couple of unique issues. I think that
> having gcc available is essential to chicken's purpose, as one is not
> likely to only use the interpreter. Installing extensions requires C
> compilation, and if one is not installing extensions and not using
> chicken's compiler, then one might as well be using any old scheme off
> the street ;-)
Right, makes sense. :-)
> If the gcc-toolchain were kept in reference (but not in the profile),
> that may be enough. The chicken compiler has options (and/or
> environment variables) to use another gcc if desired, so people who want
> to use another gcc than the one used to build chicken can still do so.
OK. Then I guess we should adjust our ‘chicken’ package so that it
hard-codes the absolute file name of ‘gcc’ and ‘ld’. Would you like to
give it a try?
> Some chicken extensions install executable programs (for example
> hyde). On other OSes they would normally be installed to
> /usr/local/bin. Obviously this would be different for guix.
This part doesn’t sound Guix-dependent. It’s more about whether
non-root users can install to, say, ~/.local, or whether only root can
install (to /usr/local/bin or similar.) WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 9:36 ` Ludovic Courtès
@ 2016-07-01 12:11 ` John J Foerch
2016-07-01 13:27 ` Thompson, David
2016-07-01 19:52 ` Ludovic Courtès
0 siblings, 2 replies; 14+ messages in thread
From: John J Foerch @ 2016-07-01 12:11 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> Installing gcc-toolchain helped, and there are no more compilation
>> errors. Another error came up in trying to install the built files.
>> Here is my log:
>>
>> <SNIP>
>
> I think we need to build CHICKEN such that it uses /var/lib instead of
> /gnu/store/…-chicken/var/lib (the latter is immutable.) I suppose
> that’s how it works on other distros, right? (With this approach only
> root can install software, though.)
>
> Do you know how to make this change?
>
> Thanks,
> Ludo’.
First a question about /var/lib, and please excuse the newbie question.
If chicken extensions were installed to /var/lib, wouldn't that go
against the spirit of guix of keeping every program isolated? Isn't
/var/lib global state?
I have just learned about 'guix import', and have the thought that a
package importer would be the better way to go. Eventually I would like
to package software that I've written in CHICKEN for GuixSD, and only a
package importer would make that feasible.
I will definitely give it a try to add such a feature to guix, and will
follow whatever advice you may have. In some ways I am still learning
the very basics of guix, so it may take me a bit to get up to speed.
Thank you,
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 9:39 ` Ludovic Courtès
@ 2016-07-01 12:16 ` John J Foerch
0 siblings, 0 replies; 14+ messages in thread
From: John J Foerch @ 2016-07-01 12:16 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>> I don't have enough experience with guix to give definite advice on
>> this, but chicken does present a couple of unique issues. I think that
>> having gcc available is essential to chicken's purpose, as one is not
>> likely to only use the interpreter. Installing extensions requires C
>> compilation, and if one is not installing extensions and not using
>> chicken's compiler, then one might as well be using any old scheme off
>> the street ;-)
>
> Right, makes sense. :-)
>
>> If the gcc-toolchain were kept in reference (but not in the profile),
>> that may be enough. The chicken compiler has options (and/or
>> environment variables) to use another gcc if desired, so people who want
>> to use another gcc than the one used to build chicken can still do so.
>
> OK. Then I guess we should adjust our ‘chicken’ package so that it
> hard-codes the absolute file name of ‘gcc’ and ‘ld’. Would you like to
> give it a try?
>
Sure!
>> Some chicken extensions install executable programs (for example
>> hyde). On other OSes they would normally be installed to
>> /usr/local/bin. Obviously this would be different for guix.
>
> This part doesn’t sound Guix-dependent. It’s more about whether
> non-root users can install to, say, ~/.local, or whether only root can
> install (to /usr/local/bin or similar.) WDYT?
>
Sorry, I don't really understand the issues at hand well enough yet to
comment. I have been looking at 'guix import', as I said in my other
message, and I now wonder if a package importer is the best way forward,
in accordance with the guix spirit.
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 12:11 ` John J Foerch
@ 2016-07-01 13:27 ` Thompson, David
2016-07-01 19:52 ` Ludovic Courtès
1 sibling, 0 replies; 14+ messages in thread
From: Thompson, David @ 2016-07-01 13:27 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
> First a question about /var/lib, and please excuse the newbie question.
> If chicken extensions were installed to /var/lib, wouldn't that go
> against the spirit of guix of keeping every program isolated? Isn't
> /var/lib global state?
Yes, but this program is not Guix. It's a completely separate package
manager, and it should work as intended.
- Dave
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 12:11 ` John J Foerch
2016-07-01 13:27 ` Thompson, David
@ 2016-07-01 19:52 ` Ludovic Courtès
2016-07-01 20:22 ` John J Foerch
1 sibling, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-07-01 19:52 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
John J Foerch <jjfoerch@earthlink.net> skribis:
> I have just learned about 'guix import', and have the thought that a
> package importer would be the better way to go. Eventually I would like
> to package software that I've written in CHICKEN for GuixSD, and only a
> package importer would make that feasible.
"Thompson, David" <dthompson2@worcester.edu> skribis:
> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>
>> First a question about /var/lib, and please excuse the newbie question.
>> If chicken extensions were installed to /var/lib, wouldn't that go
>> against the spirit of guix of keeping every program isolated? Isn't
>> /var/lib global state?
>
> Yes, but this program is not Guix. It's a completely separate package
> manager, and it should work as intended.
Agreed. So I think there are two issues at hand:
1. How to arrange our ‘chicken’ package so that ‘chicken-install’
works as intended.
2. How to import Eggs so that they can be first-class Guix packages.
#2, which means writing an importer, is definitely the most profitable
approach: It’s best as a user to have all the packages managed by the
same tool, especially if that provides isolation, transactional upgrades
and rollbacks, etc.
#1 is useful for CHICKEN users who are used to ‘chicken-install’
(similarly pip, npm, etc. are supposed to work.) It should work in the
same way as on other distros. I’ve never used it though, so I can’t
give precise advice.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 19:52 ` Ludovic Courtès
@ 2016-07-01 20:22 ` John J Foerch
2016-07-02 10:21 ` Ludovic Courtès
0 siblings, 1 reply; 14+ messages in thread
From: John J Foerch @ 2016-07-01 20:22 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> I have just learned about 'guix import', and have the thought that a
>> package importer would be the better way to go. Eventually I would like
>> to package software that I've written in CHICKEN for GuixSD, and only a
>> package importer would make that feasible.
>
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>
>>> First a question about /var/lib, and please excuse the newbie question.
>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>> against the spirit of guix of keeping every program isolated? Isn't
>>> /var/lib global state?
>>
>> Yes, but this program is not Guix. It's a completely separate package
>> manager, and it should work as intended.
>
> Agreed. So I think there are two issues at hand:
>
> 1. How to arrange our ‘chicken’ package so that ‘chicken-install’
> works as intended.
>
> 2. How to import Eggs so that they can be first-class Guix packages.
>
> #2, which means writing an importer, is definitely the most profitable
> approach: It’s best as a user to have all the packages managed by the
> same tool, especially if that provides isolation, transactional upgrades
> and rollbacks, etc.
>
> #1 is useful for CHICKEN users who are used to ‘chicken-install’
> (similarly pip, npm, etc. are supposed to work.) It should work in the
> same way as on other distros. I’ve never used it though, so I can’t
> give precise advice.
>
It installs all extensions to a single system-wide directory, with one
path component that gives the binary version. On my debian machine,
that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is
simpler than something like npm.
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-01 20:22 ` John J Foerch
@ 2016-07-02 10:21 ` Ludovic Courtès
2016-07-17 14:22 ` John J Foerch
0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-07-02 10:21 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
John J Foerch <jjfoerch@earthlink.net> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> John J Foerch <jjfoerch@earthlink.net> skribis:
>>
>>> I have just learned about 'guix import', and have the thought that a
>>> package importer would be the better way to go. Eventually I would like
>>> to package software that I've written in CHICKEN for GuixSD, and only a
>>> package importer would make that feasible.
>>
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>>
>>>> First a question about /var/lib, and please excuse the newbie question.
>>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>>> against the spirit of guix of keeping every program isolated? Isn't
>>>> /var/lib global state?
>>>
>>> Yes, but this program is not Guix. It's a completely separate package
>>> manager, and it should work as intended.
>>
>> Agreed. So I think there are two issues at hand:
>>
>> 1. How to arrange our ‘chicken’ package so that ‘chicken-install’
>> works as intended.
>>
>> 2. How to import Eggs so that they can be first-class Guix packages.
>>
>> #2, which means writing an importer, is definitely the most profitable
>> approach: It’s best as a user to have all the packages managed by the
>> same tool, especially if that provides isolation, transactional upgrades
>> and rollbacks, etc.
>>
>> #1 is useful for CHICKEN users who are used to ‘chicken-install’
>> (similarly pip, npm, etc. are supposed to work.) It should work in the
>> same way as on other distros. I’ve never used it though, so I can’t
>> give precise advice.
>>
>
> It installs all extensions to a single system-wide directory, with one
> path component that gives the binary version. On my debian machine,
> that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is
> simpler than something like npm.
Right. So to address #1, we should make sure it uses /var/lib, as
discussed earlier.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-02 10:21 ` Ludovic Courtès
@ 2016-07-17 14:22 ` John J Foerch
2016-07-17 17:45 ` Ludovic Courtès
0 siblings, 1 reply; 14+ messages in thread
From: John J Foerch @ 2016-07-17 14:22 UTC (permalink / raw)
To: help-guix
ludo@gnu.org (Ludovic Courtès) writes:
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> John J Foerch <jjfoerch@earthlink.net> skribis:
>>>
>>>> I have just learned about 'guix import', and have the thought that a
>>>> package importer would be the better way to go. Eventually I would like
>>>> to package software that I've written in CHICKEN for GuixSD, and only a
>>>> package importer would make that feasible.
>>>
>>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>>
>>>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>>>
>>>>> First a question about /var/lib, and please excuse the newbie question.
>>>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>>>> against the spirit of guix of keeping every program isolated? Isn't
>>>>> /var/lib global state?
>>>>
>>>> Yes, but this program is not Guix. It's a completely separate package
>>>> manager, and it should work as intended.
>>>
>>> Agreed. So I think there are two issues at hand:
>>>
>>> 1. How to arrange our ‘chicken’ package so that ‘chicken-install’
>>> works as intended.
>>>
>>> 2. How to import Eggs so that they can be first-class Guix packages.
>>>
>>> #2, which means writing an importer, is definitely the most profitable
>>> approach: It’s best as a user to have all the packages managed by the
>>> same tool, especially if that provides isolation, transactional upgrades
>>> and rollbacks, etc.
>>>
>>> #1 is useful for CHICKEN users who are used to ‘chicken-install’
>>> (similarly pip, npm, etc. are supposed to work.) It should work in the
>>> same way as on other distros. I’ve never used it though, so I can’t
>>> give precise advice.
>>>
>>
>> It installs all extensions to a single system-wide directory, with one
>> path component that gives the binary version. On my debian machine,
>> that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is
>> simpler than something like npm.
>
> Right. So to address #1, we should make sure it uses /var/lib, as
> discussed earlier.
>
I'm finally getting back to this. One point about chicken is that it
does not support multiple extension directories, only one. They go into
<VARDIR>/chicken/<BINARY-VERSION>. This introduces a difficulty because
if VARDIR is /var/lib, then the default extensions (that come with
chicken) get installed to a global directory. The chicken-install
system will then work, but in the future when we add a package importer,
imported packages would also go into this global directory.
If on the other hand, VARDIR is (string-append out "/var/lib") the
default extensions and imported extensions go to the right place, but
manual chicken-install cannot write to that location.
Any further thoughts on this, given that information?
--
John Foerch
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme
2016-07-17 14:22 ` John J Foerch
@ 2016-07-17 17:45 ` Ludovic Courtès
0 siblings, 0 replies; 14+ messages in thread
From: Ludovic Courtès @ 2016-07-17 17:45 UTC (permalink / raw)
To: John J Foerch; +Cc: help-guix
Hello!
John J Foerch <jjfoerch@earthlink.net> skribis:
> I'm finally getting back to this. One point about chicken is that it
> does not support multiple extension directories, only one. They go into
> <VARDIR>/chicken/<BINARY-VERSION>. This introduces a difficulty because
> if VARDIR is /var/lib, then the default extensions (that come with
> chicken) get installed to a global directory. The chicken-install
> system will then work, but in the future when we add a package importer,
> imported packages would also go into this global directory.
>
> If on the other hand, VARDIR is (string-append out "/var/lib") the
> default extensions and imported extensions go to the right place, but
> manual chicken-install cannot write to that location.
>
> Any further thoughts on this, given that information?
Ouch, that’s a problem.
Nixpkgs uses VARDIR=OUT/var/lib, meaning that chicken-install does not
work.
However, it also contains an optional patch that allows extensions to be
searched for elsewhere:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/chicken/0001-Introduce-CHICKEN_REPOSITORY_EXTRA.patch
I think the best course of action would be to submit this change
upstream, if it hasn’t been done already. It’s useful beyond Nix and
Guix, so it probably makes sense to include it.
In the meantime, I would (temporarily) sacrifice chicken-install in
favor of an Egg importer.
WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-07-17 17:45 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-30 19:11 chicken scheme John J Foerch
2016-06-30 21:27 ` Ludovic Courtès
2016-06-30 21:43 ` John J Foerch
2016-07-01 9:36 ` Ludovic Courtès
2016-07-01 12:11 ` John J Foerch
2016-07-01 13:27 ` Thompson, David
2016-07-01 19:52 ` Ludovic Courtès
2016-07-01 20:22 ` John J Foerch
2016-07-02 10:21 ` Ludovic Courtès
2016-07-17 14:22 ` John J Foerch
2016-07-17 17:45 ` Ludovic Courtès
2016-06-30 22:05 ` John J Foerch
2016-07-01 9:39 ` Ludovic Courtès
2016-07-01 12:16 ` John J Foerch
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).