Is it possible add 'Guix package manager without "make install"' to guix doc?

Is it possible add 'Guix package manager without "make install"' to guix doc?

[Feng Shu]

Christopher Allan Webber's blog: Guix package manager without "make install"


http://dustycloud.org/blog/guix-package-manager-without-make-install/


seem very useful, is it possible add to guix doc?

Thanks!

-- 

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Christopher Allan Webber]

Feng Shu writes:

> Christopher Allan Webber's blog: Guix package manager without "make install"
>
>
> http://dustycloud.org/blog/guix-package-manager-without-make-install/
>
> seem very useful, is it possible add to guix doc?
>
> Thanks!

I'd have no problems adding it to the doc and licensing it as GFDL
appropriately if people think it would be useful.

It has been referenced a lot on IRC lately, it seems.

However I'm not sure the way it's written currently could be directly
dumped into the documentation.  It seems to need adjustments, though I'm
not sure exactly how it could be adjusted.

 - Chris

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Feng Shu writes:
>
>> Christopher Allan Webber's blog: Guix package manager without "make install"
>>
>>
>> http://dustycloud.org/blog/guix-package-manager-without-make-install/
>>
>> seem very useful, is it possible add to guix doc?
>>
>> Thanks!
>
> I'd have no problems adding it to the doc and licensing it as GFDL
> appropriately if people think it would be useful.
>
> It has been referenced a lot on IRC lately, it seems.
>
> However I'm not sure the way it's written currently could be directly
> dumped into the documentation.  It seems to need adjustments, though I'm
> not sure exactly how it could be adjusted.

What I would like is to have a “Guix Development” section in the manual,
along the lines of “Running Guix before it is installed” in ‘HACKING’,
but marked as a developer’s trick.

I do not feel like explicitly inviting users to do “alias
guix=~/guix/pre-inst-env guix”, though, because that seems a bit hacky.
;-)

WDYT?

For the Emacs part, I think setting ‘load-path’,
‘geiser-guile-load-path’, and ‘guix-load-path’ would be enough.  Maybe
that part of the doc needs to be adjusted?

Thanks,
Ludo’.

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> Feng Shu writes:
>>
>>> Christopher Allan Webber's blog: Guix package manager without "make install"
>>>
>>>
>>> http://dustycloud.org/blog/guix-package-manager-without-make-install/
>>>
>>> seem very useful, is it possible add to guix doc?
>>>
>>> Thanks!
>>
>> I'd have no problems adding it to the doc and licensing it as GFDL
>> appropriately if people think it would be useful.
>>
>> It has been referenced a lot on IRC lately, it seems.
>>
>> However I'm not sure the way it's written currently could be directly
>> dumped into the documentation.  It seems to need adjustments, though I'm
>> not sure exactly how it could be adjusted.
>
> What I would like is to have a “Guix Development” section in the manual,
> along the lines of “Running Guix before it is installed” in ‘HACKING’,
> but marked as a developer’s trick.

That sounds like a good idea.

> I do not feel like explicitly inviting users to do “alias
> guix=~/guix/pre-inst-env guix”, though, because that seems a bit hacky.
> ;-)
>
> WDYT?

Do you have an alternative suggestion so that running guix easily in
bash is possible?  Per my current blogpost, this alias is only set up
after running guix-enable.  I agree it's not ideal, and am open to alternatives.

> For the Emacs part, I think setting ‘load-path’,
> ‘geiser-guile-load-path’, and ‘guix-load-path’ would be enough.  Maybe
> that part of the doc needs to be adjusted?

Does that work?  I originally had some different settings but I found
that the right things did not seem to be on the path from the guile
being launched.  Originally I set environment variables from within
emacs (yikes!) so using the pre-install-env version was a
simplification.

Does anyone have an alternative .emacs setup they've tested without a
"make install" that they know works?

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Ludovic Courtès writes:

[...]

>> What I would like is to have a “Guix Development” section in the manual,
>> along the lines of “Running Guix before it is installed” in ‘HACKING’,
>> but marked as a developer’s trick.
>
> That sounds like a good idea.

Done in c71979f.  Comments & patches welcome!  :-)

>> I do not feel like explicitly inviting users to do “alias
>> guix=~/guix/pre-inst-env guix”, though, because that seems a bit hacky.
>> ;-)
>>
>> WDYT?
>
> Do you have an alternative suggestion so that running guix easily in
> bash is possible?  Per my current blogpost, this alias is only set up
> after running guix-enable.  I agree it's not ideal, and am open to alternatives.

I think if we document ./pre-inst-env, then it’ll be clear that people
can do this sort of thing.  All I’m saying is that I’d rather not
document the technique from your post in extenso because that’s not very
nice.

I confess that, being biased as I am ;-), I don’t fully understand the
rationale: after all, you’re already installing /gnu and
/usr/local/var/guix, so why is it so important to not install two more
files in /usr/local/bin?

But really, it’s just me being ignorant about the use case, so I’m happy
to read what people think/want.

>> For the Emacs part, I think setting ‘load-path’,
>> ‘geiser-guile-load-path’, and ‘guix-load-path’ would be enough.  Maybe
>> that part of the doc needs to be adjusted?
>
> Does that work?

I have ~/src/guix/emacs in ‘load-path’ and ~/src/guix in
‘geiser-guile-load-path’, and that’s all it takes, AFAICS.  Alex?

Thanks for your feedback!

Ludo’.

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> What I would like is to have a “Guix Development” section in the manual,
>>> along the lines of “Running Guix before it is installed” in ‘HACKING’,
>>> but marked as a developer’s trick.
>>
>> That sounds like a good idea.
>
> Done in c71979f.  Comments & patches welcome!  :-)

Hey nice!

>>> I do not feel like explicitly inviting users to do “alias
>>> guix=~/guix/pre-inst-env guix”, though, because that seems a bit hacky.
>>> ;-)
>>>
>>> WDYT?
>>
>> Do you have an alternative suggestion so that running guix easily in
>> bash is possible?  Per my current blogpost, this alias is only set up
>> after running guix-enable.  I agree it's not ideal, and am open to alternatives.
>
> I think if we document ./pre-inst-env, then it’ll be clear that people
> can do this sort of thing.  All I’m saying is that I’d rather not
> document the technique from your post in extenso because that’s not very
> nice.

Makes sense.

Btw a bit of a tangent but ./pre-inst-env is an interesting technique
that I learned for my own Guile hacking stuff because Dave Thompson
pointed it out to me in Sly (which in turn borrowed from Guix), and
learning that I could hack on things by running "./pre-inst-env guile
--listen" then using connect-to-guile in geiser... that's another one of
those techniques which seems known in the community but I only found out
because I know someone who knows. :) But it's a good pattern!  I wonder
if we should have recommendations on how to hack on and package guile
stuff somewhere.  But I guess that's a guile-dev or guile-user
conversation...

> I confess that, being biased as I am ;-), I don’t fully understand the
> rationale: after all, you’re already installing /gnu and
> /usr/local/var/guix, so why is it so important to not install two more
> files in /usr/local/bin?
>
> But really, it’s just me being ignorant about the use case, so I’m happy
> to read what people think/want.

Well, for me it's two reasons:
 - I've had pain with things being dumped to /usr/local/ and then
   trouble removing the whole thing before, not to mention forgetting
   that they're there.  I try to avoid installing to my system unless
   using a package manager (and now, guix counts as one of those ;))
 - I also wanted to hack on guix and guix packages... I guess, maybe
   it's possible to do with a make install?  But given that I'm
   interactively hacking on the project, wouldn't I want to not have to
   do a "make install" every time and instead use whatever's in git?

   Similarly, I've wondered, how do GuixSD users hack on Guix, if Guix
   is already installed system-wide?  Genuine question!

>>> For the Emacs part, I think setting ‘load-path’,
>>> ‘geiser-guile-load-path’, and ‘guix-load-path’ would be enough.  Maybe
>>> that part of the doc needs to be adjusted?
>>
>> Does that work?
>
> I have ~/src/guix/emacs in ‘load-path’ and ~/src/guix in
> ‘geiser-guile-load-path’, and that’s all it takes, AFAICS.  Alex?

Aha, ok!

> Thanks for your feedback!
>
> Ludo’.

Thanks for integrating!

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Alex Kost]

Ludovic Courtès (2015-05-23 16:59 +0300) wrote:

> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> For the Emacs part, I think setting ‘load-path’,
>>> ‘geiser-guile-load-path’, and ‘guix-load-path’ would be enough.  Maybe
>>> that part of the doc needs to be adjusted?
>>
>> Does that work?
>
> I have ~/src/guix/emacs in ‘load-path’ and ~/src/guix in
> ‘geiser-guile-load-path’, and that’s all it takes, AFAICS.  Alex?

Requiring 'guix-init' is essential (and it is required by
"site-start.el" you made in commit 0a05176 :-)); without it you wouldn't
even have "M-x guix-…" commands.

As for me, I use almost the same settings as Christopher, except I don't
modify 'guix-guile-program' (I didn't even realize that it may be used
like this – very clever!)  Instead I just made "~/.config/guix/latest" a
symlink to my "~/src/guix" directory.

-- 
Alex

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Ludovic Courtès writes:

[...]

>> I confess that, being biased as I am ;-), I don’t fully understand the
>> rationale: after all, you’re already installing /gnu and
>> /usr/local/var/guix, so why is it so important to not install two more
>> files in /usr/local/bin?
>>
>> But really, it’s just me being ignorant about the use case, so I’m happy
>> to read what people think/want.
>
> Well, for me it's two reasons:
>  - I've had pain with things being dumped to /usr/local/ and then
>    trouble removing the whole thing before, not to mention forgetting
>    that they're there.  I try to avoid installing to my system unless
>    using a package manager (and now, guix counts as one of those ;))

OK.

>  - I also wanted to hack on guix and guix packages... I guess, maybe
>    it's possible to do with a make install?  But given that I'm
>    interactively hacking on the project, wouldn't I want to not have to
>    do a "make install" every time and instead use whatever's in git?

Right, I wouldn’t want to run “make install” every time a new package is
added.  ;-)

>    Similarly, I've wondered, how do GuixSD users hack on Guix, if Guix
>    is already installed system-wide?  Genuine question!

I definitely use ./pre-inst-env while hacking, plus Geiser with the
appropriate ‘geiser-guile-load-path’.

I try to force myself to distinguish between hacking the thing and using
it.  So I put my “end-user” hat on (don’t laugh!) and run ‘guix pull’
and ‘guix’ (without ./pre-inst-env) when I want to fiddle with my
profile or unrelated development environments.

So my ~/.config/guix/latest is usually slightly behind Git, but that’s
not necessarily a bad thing (sort-of like ‘testing’ vs. ‘unstable’ ;-)).

Ludo’.

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Mathieu Lirzin]

ludo@gnu.org (Ludovic Courtès) writes:

> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>>    Similarly, I've wondered, how do GuixSD users hack on Guix, if Guix
>>    is already installed system-wide?  Genuine question!
>
> I definitely use ./pre-inst-env while hacking, plus Geiser with the
> appropriate ‘geiser-guile-load-path’.
>
> I try to force myself to distinguish between hacking the thing and using
> it.  So I put my “end-user” hat on (don’t laugh!) and run ‘guix pull’
> and ‘guix’ (without ./pre-inst-env) when I want to fiddle with my
> profile or unrelated development environments.
>
> So my ~/.config/guix/latest is usually slightly behind Git, but that’s
> not necessarily a bad thing (sort-of like ‘testing’ vs. ‘unstable’ ;-)).
>
> Ludo’.

This statement should definitely complement the documentation in HACKING.

--
Mathieu Lirzin

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Ludovic Courtès]

Mathieu Lirzin <mthl@openmailbox.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>
>>>    Similarly, I've wondered, how do GuixSD users hack on Guix, if Guix
>>>    is already installed system-wide?  Genuine question!
>>
>> I definitely use ./pre-inst-env while hacking, plus Geiser with the
>> appropriate ‘geiser-guile-load-path’.
>>
>> I try to force myself to distinguish between hacking the thing and using
>> it.  So I put my “end-user” hat on (don’t laugh!) and run ‘guix pull’
>> and ‘guix’ (without ./pre-inst-env) when I want to fiddle with my
>> profile or unrelated development environments.
>>
>> So my ~/.config/guix/latest is usually slightly behind Git, but that’s
>> not necessarily a bad thing (sort-of like ‘testing’ vs. ‘unstable’ ;-)).
>>
>> Ludo’.
>
> This statement should definitely complement the documentation in HACKING.

Where/how would you suggest adding it?

Ludo’.

Re: Is it possible add 'Guix package manager without "make install"' to guix doc?

[Mathieu Lirzin]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl@openmailbox.org> skribis:
>>
>> This statement should definitely complement the documentation in HACKING.
>
> Where/how would you suggest adding it?

When reacting, I didn't realize that most of your statement is actually
documented in the recent "Running Guix Before It Is Installed" node in
doc/guix.texi.

Nevertheless, I find it not really relevant to give hacking information
in chapter 'Installation'. The attached patch tries to give a better
consistency in the location of these useful informations.

Even if I find this patch appropriate ;-), my personnal preference would
be to delete HACKING, and move all its informations in the chapter
'Contributing' of the Holy Bible (with appropriate refinement of
course!) and refer to it in README. Opinions about this?

--
Mathieu Lirzin


[-- Attachment #2: 0001-doc-Move-hacker-tricks-to-HACKING.patch --]
[-- Type: text/x-diff, Size: 6636 bytes --]

From 887f2640da75d93560f49edca6198d294d809a41 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl@openmailbox.org>
Date: Sat, 30 May 2015 01:47:21 +0200
Subject: [PATCH] doc: Move hacker tricks to 'HACKING'.

* doc/guix.texi (Running Guix before it is installed): Delete node.
  (Packaging Guidelines): Adapt to it.
* HACKING (Running Guix before it is installed): Delete section.
  (Doing Stuff!): New section.
  (Building from Git, Doing Stuff!, The Perfect Setup): Split informations.
---
 HACKING       | 33 +++++++++++++++++++++++++++++----
 doc/guix.texi | 43 +------------------------------------------
 2 files changed, 30 insertions(+), 46 deletions(-)

diff --git a/HACKING b/HACKING
index cf10ba5..e5f854b 100644
--- a/HACKING
+++ b/HACKING
@@ -4,6 +4,7 @@
 
 Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
 Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
+Copyright © 2015 Mathieu Lirzin <mthl@openmailbox.org>
 Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
 
   Copying and distribution of this file, with or without modification,
@@ -13,8 +14,10 @@ Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
 
 * Building from Git
 
-When building Guix from a checkout, the following packages are required in
-addition to those mentioned in the installation instructions:
+If you want to hack Guix itself, it is recommended to use the latest version
+from the Git repository.  When building Guix from a checkout, the following
+packages are required in addition to those mentioned in the installation
+instructions:
 
   - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]]
   - [[http://www.gnu.org/software/automake/][GNU Automake]]
@@ -44,9 +47,26 @@ Finally, you have to invoke ‘make check’ to run tests.  If anything fails,
 take a look at “info '(guix) Installation'” or send a message to
 <guix-devel@gnu.org>.
 
-* Running Guix before it is installed
+* Doing stuff!
 
-See the same-named section in the manual.
+In order to keep a sane working environment, you will find it useful to test
+the changes made in your local source tree checkout without actually
+installing them.  So that you can distinguish between your “end-user” hat and
+your “motley” costume.
+
+To that end, all the command-line tools can be used even if you have not run
+"make install".  To do that, prefix each command with =./pre-inst-env= (this
+script lives in the top build tree of Guix), as in:
+
+  $ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
+  $ ./pre-inst-env guix build hello
+
+Similarly, for a Guile session using the Guix modules:
+
+  $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
+
+The =pre-inst-env= script sets up all the environment variables necessary to
+support this, including ‘PATH’ and ‘GUILE_LOAD_PATH’.
 
 * The Perfect Setup
 
@@ -59,6 +79,11 @@ Geiser allows for interactive and incremental development from within
 Emacs: code compilation and evaluation from within buffers, access to
 on-line documentation (docstrings), context-sensitive completion, M-. to
 jump to an object definition, a REPL to try out your code, and more.
+For convenient Guix development, make sure to augment Guile’s load path
+so that it finds source files from your checkout:
+
+  ;; Assuming the Guix checkout is in ~/src/guix.
+  (add-to-list 'geiser-guile-load-path "~/src/guix")
 
 To actually edit the code, Emacs already has a neat Scheme mode.  But in
 addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]].  It provides facilities to
diff --git a/doc/guix.texi b/doc/guix.texi
index 2d10ec9..6dbd76e 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -88,7 +88,6 @@ Installation
 * Running the Test Suite::      Testing Guix.
 * Setting Up the Daemon::       Preparing the build daemon's environment.
 * Invoking guix-daemon::        Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
 
 Setting Up the Daemon
 
@@ -253,7 +252,6 @@ instead, you want to install the complete GNU operating system,
 * Running the Test Suite::      Testing Guix.
 * Setting Up the Daemon::       Preparing the build daemon's environment.
 * Invoking guix-daemon::        Running the build daemon.
-* Running Guix Before It Is Installed::     Hacker tricks.
 @end menu
 
 @node Binary Installation
@@ -835,44 +833,6 @@ useful in exceptional circumstances, such as if you need to run several
 daemons on the same machine.
 @end table
 
-@node Running Guix Before It Is Installed
-@section Running Guix Before It Is Installed
-
-If you are hacking Guix itself---which is a good idea!---you will find
-it useful to test the changes made in your local source tree checkout
-without actually installing them.
-
-To that end, all the command-line tools can be used even if you have not
-run @command{make install}.  To do that, prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix), as in:
-
-@example
-$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
-$ ./pre-inst-env guix build hello
-@end example
-
-@noindent
-Similarly, for a Guile session using the Guix modules:
-
-@example
-$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
-@end example
-
-The @command{pre-inst-env} script sets up all the environment variables
-necessary to support this, including @code{PATH} and
-@code{GUILE_LOAD_PATH}.
-
-If you are hacking Guix from Emacs using the wonderful Geiser
-(@pxref{Introduction,,, geiser, Geiser User Manual}), make sure to
-augment Guile's load path so that it finds source files from your
-checkout:
-
-@lisp
-;; Assuming the Guix checkout is in ~/src/guix.
-(add-to-list 'geiser-guile-load-path "~/src/guix")
-@end lisp
-
 
 @c *********************************************************************
 @node Package Management
@@ -6300,8 +6260,7 @@ creating packages.  For more information on package definitions,
 Once a package definition is in place, stored in a file in the Guix
 source tree, it can be tested using the @command{guix build} command
 (@pxref{Invoking guix build}).  For example, assuming the new package is
-called @code{gnew}, you may run this command from the Guix build tree
-(@pxref{Running Guix Before It Is Installed}):
+called @code{gnew}, you may run this command from the Guix build tree:
 
 @example
 ./pre-inst-env guix build gnew --keep-failed
-- 
2.1.4

Merging ‘HACKING’ in the manual?

[Ludovic Courtès]

Mathieu Lirzin <mthl@openmailbox.org> skribis:

> When reacting, I didn't realize that most of your statement is actually
> documented in the recent "Running Guix Before It Is Installed" node in
> doc/guix.texi.
>
> Nevertheless, I find it not really relevant to give hacking information
> in chapter 'Installation'.

Agreed but...

> The attached patch tries to give a better consistency in the location
> of these useful informations.

... c71979f just did the opposite move, so no.  :-)

> Even if I find this patch appropriate ;-), my personnal preference would
> be to delete HACKING, and move all its informations in the chapter
> 'Contributing' of the Holy Bible (with appropriate refinement of
> course!) and refer to it in README. Opinions about this?

Yeah, probably.  I’m not completely sure about moving things like patch
submission and coding style in there; on one hand, it’s not something
one would expect in a “user manual”, but on the other hand, it’s nice to
have everything consistently maintained in one place.

Another option would be to have a second .texi document for these things
(like Findutils, which has a ‘findutils-maint’ document.)

What do people think?

Ludo’.

Re: Merging ‘HACKING’ in the manual?

[Luis Felipe López Acevedo]

On 2015-05-31 14:20, ludo@gnu.org wrote:
> Mathieu Lirzin <mthl@openmailbox.org> skribis:
> 
>> When reacting, I didn't realize that most of your statement is 
>> actually
>> documented in the recent "Running Guix Before It Is Installed" node in
>> doc/guix.texi.
>> 
>> Nevertheless, I find it not really relevant to give hacking 
>> information
>> in chapter 'Installation'.
> 
> Agreed but...
> 
>> The attached patch tries to give a better consistency in the location
>> of these useful informations.
> 
> ... c71979f just did the opposite move, so no.  :-)
> 
>> Even if I find this patch appropriate ;-), my personnal preference 
>> would
>> be to delete HACKING, and move all its informations in the chapter
>> 'Contributing' of the Holy Bible (with appropriate refinement of
>> course!) and refer to it in README. Opinions about this?
> 
> Yeah, probably.  I’m not completely sure about moving things like patch
> submission and coding style in there; on one hand, it’s not something
> one would expect in a “user manual”, but on the other hand, it’s nice 
> to
> have everything consistently maintained in one place.
> 
> Another option would be to have a second .texi document for these 
> things
> (like Findutils, which has a ‘findutils-maint’ document.)
> 
> What do people think?

I like GNUnet's use of "handbooks" to separate information. They have 
Installation Handbook, User Handbook, and Developer Handbook. I think 
something similar could work well for Guix.


-- 
Luis Felipe López Acevedo

Re: Merging ‘HACKING’ in the manual?

[Alex Kost]

Ludovic Courtès (2015-05-31 22:20 +0300) wrote:

> Mathieu Lirzin <mthl@openmailbox.org> skribis:
>
>> When reacting, I didn't realize that most of your statement is actually
>> documented in the recent "Running Guix Before It Is Installed" node in
>> doc/guix.texi.
>>
>> Nevertheless, I find it not really relevant to give hacking information
>> in chapter 'Installation'.
>
> Agreed but...
>
>> The attached patch tries to give a better consistency in the location
>> of these useful informations.
>
> ... c71979f just did the opposite move, so no.  :-)
>
>> Even if I find this patch appropriate ;-), my personnal preference would
>> be to delete HACKING, and move all its informations in the chapter
>> 'Contributing' of the Holy Bible (with appropriate refinement of
>> course!) and refer to it in README. Opinions about this?
>
> Yeah, probably.  I’m not completely sure about moving things like patch
> submission and coding style in there; on one hand, it’s not something
> one would expect in a “user manual”, but on the other hand, it’s nice to
> have everything consistently maintained in one place.
>
> Another option would be to have a second .texi document for these things
> (like Findutils, which has a ‘findutils-maint’ document.)
>
> What do people think?

I don't have a strong opinion.  It might be a separate “Hacking” (or
whatever) section in the current manual or another “maint” info manual.
Both solutions look good to me.  I have a slight preference for the
first variant though.

-- 
Alex

Re: Merging ‘HACKING’ in the manual?

[Ludovic Courtès]

Luis Felipe López Acevedo <felipe.lopez@openmailbox.org> skribis:

> I like GNUnet's use of "handbooks" to separate information. They have
> Installation Handbook, User Handbook, and Developer Handbook. I think
> something similar could work well for Guix.

We should aim to blur the distinction between developers and users, and
I think we have the right technical environment for that
(“configuration” files that happen to actually be Scheme, “package
recipes” that happen to be Scheme as well, etc.)  So I’m in favor of
keeping the technical information all grouped together.

I think the installations sections are fine in the main manual.

The question here is more about the organizational documentation.

Alex Kost <alezost@gmail.com> skribis:

> I don't have a strong opinion.  It might be a separate “Hacking” (or
> whatever) section in the current manual or another “maint” info manual.
> Both solutions look good to me.  I have a slight preference for the
> first variant though.

Yes, that’s also my current inclination.

Thanks for your feedback!

Ludo’.

Re: Merging ‘HACKING’ in the manual?

[Ricardo Wurmus]

> We should aim to blur the distinction between developers and users, and
> I think we have the right technical environment for that
> (“configuration” files that happen to actually be Scheme, “package
> recipes” that happen to be Scheme as well, etc.)  So I’m in favor of
> keeping the technical information all grouped together.

I agree.  Keeping it all together also encourages users to make use of
their software freedom to modify recipes, add their own and possibly
submit them upstream.

>> I don't have a strong opinion.  It might be a separate “Hacking” (or
>> whatever) section in the current manual or another “maint” info manual.
>> Both solutions look good to me.  I have a slight preference for the
>> first variant though.
>
> Yes, that’s also my current inclination.

I, too, would prefer to have it as a section in the current manual, but
that's primarily because I never remember where I can find the
information I'm looking for.  It's easier to have it in the same manual,
organised in an order that goes from casual user to contributor.

~~ Ricardo

Re: Merging ‘HACKING’ in the manual?

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

>>> I don't have a strong opinion.  It might be a separate “Hacking” (or
>>> whatever) section in the current manual or another “maint” info manual.
>>> Both solutions look good to me.  I have a slight preference for the
>>> first variant though.
>>
>> Yes, that’s also my current inclination.
>
> I, too, would prefer to have it as a section in the current manual, but
> that's primarily because I never remember where I can find the
> information I'm looking for.  It's easier to have it in the same manual,
> organised in an order that goes from casual user to contributor.

OK, so Mathieu, if you’re still here ;-) : What about adding
sub-sections to “Contributing”, with material mostly taken from
‘HACKING’ (with the exception of “Commit Access”, I think), and also
with “Running Guix Before It Is Installed” moved there?

Thanks for your feedback,
Ludo’.

Re: Merging ‘HACKING’ in the manual?

[Mathieu Lirzin]

ludo@gnu.org (Ludovic Courtès) writes:

> OK, so Mathieu, if you’re still here ;-) : What about adding
> sub-sections to “Contributing”, with material mostly taken from
> ‘HACKING’ (with the exception of “Commit Access”, I think), and also
> with “Running Guix Before It Is Installed” moved there?

I will do that!

--
Mathieu Lirzin