Multiple versions

Multiple versions

[Dmitry Bogatov]

Hello!

In my attempt to understand Guix, get used to it and use
it's advantages, I got following considerations that I would like
to discuss with more experienced users:

  * Guix provides first-class support for multiple versions of packages.
    By first class I mean, that you don't need to do anything special
    to get this support, unlike Gentoo, which for example, supports
    multiple versions of Python and Ruby, but not Guile or GHC.

    But reading 'gnu/packages/haskell.scm' I see same, single-versioned
    packaging in style of Debian. Why? If we would provide package for
    every version of library 'foo' and every version of 'ghc', Guix
    would replace `haskell-stack' tool, and, eventually became The Ring
    to rule stack,virtualenv,bundler,...

    Or am I missing the point, and libraries are packaged only as long
    they are needed for some program?

  * By default, ~/.guix-profile/share/emacs/site-lisp/guix.d is not in
    load-path. `emacs-no-x` exports no variables. So, if I install
    some emacs library, like `emacs-f`, evaluating (require 'f) in emacs
    fails. It is... unexpected. Is it intended behaviour?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Multiple versions

[Pjotr Prins]

Hi Dmitry,

On Sat, Dec 26, 2015 at 11:02:52PM +0000, Dmitry Bogatov wrote:
> Hello!
> 
> In my attempt to understand Guix, get used to it and use
> it's advantages, I got following considerations that I would like
> to discuss with more experienced users:
> 
>   * Guix provides first-class support for multiple versions of packages.
>     By first class I mean, that you don't need to do anything special
>     to get this support, unlike Gentoo, which for example, supports
>     multiple versions of Python and Ruby, but not Guile or GHC.
> 
>     But reading 'gnu/packages/haskell.scm' I see same, single-versioned
>     packaging in style of Debian. Why? If we would provide package for
>     every version of library 'foo' and every version of 'ghc', Guix
>     would replace `haskell-stack' tool, and, eventually became The Ring
>     to rule stack,virtualenv,bundler,...
> 
>     Or am I missing the point, and libraries are packaged only as long
>     they are needed for some program?

You can mix versions. Maybe this helps

  https://github.com/pjotrp/guix-notes/blob/master/REPRODUCIBLE.org

Re: Multiple versions

[Dmitry Bogatov]

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

> > In my attempt to understand Guix, get used to it and use
> > it's advantages, I got following considerations that I would like
> > to discuss with more experienced users:
> > 
> >   * Guix provides first-class support for multiple versions of packages.
> >     By first class I mean, that you don't need to do anything special
> >     to get this support, unlike Gentoo, which for example, supports
> >     multiple versions of Python and Ruby, but not Guile or GHC.
> > 
> >     But reading 'gnu/packages/haskell.scm' I see same, single-versioned
> >     packaging in style of Debian. Why? If we would provide package for
> >     every version of library 'foo' and every version of 'ghc', Guix
> >     would replace `haskell-stack' tool, and, eventually became The Ring
> >     to rule stack,virtualenv,bundler,...
> > 
> >     Or am I missing the point, and libraries are packaged only as long
> >     they are needed for some program?
> You can mix versions. Maybe this helps
> 
>   https://github.com/pjotrp/guix-notes/blob/master/REPRODUCIBLE.org

Seems I failed to make myself clear. Let me try again.

Currently, I am at master branch. I want install parallel-20151122.
But it is gone since 0877e. I propose to keep *all* versions,
but just 'parallel' refer to latest.

In case of haskell/python/ruby libraries, I propose keep all versions
multiplied by every version of compiler/interpreter.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple versions

[Andreas Enge]

On Sun, Dec 27, 2015 at 12:20:27PM +0300, Dmitry Bogatov wrote:
> Currently, I am at master branch. I want install parallel-20151122.
> But it is gone since 0877e. I propose to keep *all* versions,
> but just 'parallel' refer to latest.

This would be a nightmare to maintain. And what do you do about security
updates? If libfoo-1.1.7 fixes a critical security bug, who would backport
this to libfoo-1.0.x and libfoo-1.1.0 to libfoo-1.1.6?

Then there is the combinatorial explosion. If you have 20 libraries in
10 versions each that are needed to build a derived binary, then there
will be 10^20 possible combinations. Which of them would you like to
support?

Our general policy is to keep only the latest version, except for special
cases where people see a point in keeping older versions (script languages,
libraries like qt with two major versions supported in parallel, and so on).

What is your use case? If you want reproducibility, it could make sense
to simply stick to a given git commit. If you just need a particular older
version of some code, you could keep it in your separate tree.

Andreas

Re: Multiple versions

[Dmitry Bogatov]

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

* Andreas Enge <andreas@enge.fr> [2015-12-27 10:48:32+0100]
> On Sun, Dec 27, 2015 at 12:20:27PM +0300, Dmitry Bogatov wrote:
> > Currently, I am at master branch. I want install parallel-20151122.
> > But it is gone since 0877e. I propose to keep *all* versions,
> > but just 'parallel' refer to latest.
> 
> This would be a nightmare to maintain. And what do you do about security
> updates? If libfoo-1.1.7 fixes a critical security bug, who would backport
> this to libfoo-1.0.x and libfoo-1.1.0 to libfoo-1.1.6?

Drop old versions, or provide a warning to user in such emergency case.
After all, user have right to believe, that this particular bug is
not relevant to him

> Then there is the combinatorial explosion. If you have 20 libraries in
> 10 versions each that are needed to build a derived binary, then there
> will be 10^20 possible combinations. Which of them would you like to
> support?

Build binaries with latest versions of libraries and compilers.

> Our general policy is to keep only the latest version, except for special
> cases where people see a point in keeping older versions (script languages,
> libraries like qt with two major versions supported in parallel, and so on).

> What is your use case? If you want reproducibility, it could make sense
> to simply stick to a given git commit. If you just need a particular older

My use case is that I want to be able to install every version of
any haskell library and every version of ghc for testing purposes.

For example, I write code, that uses ghc-7.10 with lens-4.13. Will it
work with ghc-7.6(Debian stable) and lens-4.1.2.1? This versions are
important to me, but some other person may have another reference.

Yes, there is combinatorics, but not too terrible. ~1000 packages, 4 ghc
versions -> 4000 <package> variables.

Ah, and I do not propose to actually support, for example,
ghc7.6-lens-4.13. If it fails to build, that it is dropped.
Some kind of automatization and integration with hydra would
be useful.

PS. Let's also discuss Emacs 'load-path'.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple versions

[Ricardo Wurmus]

Dmitry Bogatov <KAction@gnu.org> writes:

>> Then there is the combinatorial explosion. If you have 20 libraries in
>> 10 versions each that are needed to build a derived binary, then there
>> will be 10^20 possible combinations. Which of them would you like to
>> support?
>
> Build binaries with latest versions of libraries and compilers.
>
>> Our general policy is to keep only the latest version, except for special
>> cases where people see a point in keeping older versions (script languages,
>> libraries like qt with two major versions supported in parallel, and so on).
>
>> What is your use case? If you want reproducibility, it could make sense
>> to simply stick to a given git commit. If you just need a particular older
>
> My use case is that I want to be able to install every version of
> any haskell library and every version of ghc for testing purposes.
>
> For example, I write code, that uses ghc-7.10 with lens-4.13. Will it
> work with ghc-7.6(Debian stable) and lens-4.1.2.1? This versions are
> important to me, but some other person may have another reference.

This doesn’t seem to be a useful way for the Guix project as such to use
our limited resources.

However, Guix is a library and packages are just Scheme values.  You can
write a procedure that recursively replaces the GHC value throughout the
graph of a given package.  Then you can build variants of the package
graph that use a different version of GHC.

> Yes, there is combinatorics, but not too terrible. ~1000 packages, 4 ghc
> versions -> 4000 <package> variables.

This is only for different versions of GHC, but not different versions
of packages such as lens.

> Ah, and I do not propose to actually support, for example,
> ghc7.6-lens-4.13. If it fails to build, that it is dropped.

Then it may be better to do this on a machine dedicated to the task of
testing Haskell package combinations.

> Some kind of automatization and integration with hydra would
> be useful.

Using our main Hydra instance for this seems like wasting resources that
could be used for other purposes more closely related to the goals of
the Guix project.

~~ Ricardo

Re: Multiple versions

[Pjotr Prins]

On Sun, Dec 27, 2015 at 12:20:27PM +0300, Dmitry Bogatov wrote:
> Currently, I am at master branch. I want install parallel-20151122.
> But it is gone since 0877e. I propose to keep *all* versions,
> but just 'parallel' refer to latest.

Use a combination of git hash values (to generate the versions) and
guix profiles (to manage them at the same time).

> In case of haskell/python/ruby libraries, I propose keep all versions
> multiplied by every version of compiler/interpreter.

I do the same with Ruby using profiles. I have any number of interpreters
installed for testing and any number of libraries using either guix or
the lib path with a profile in there.

It can all be done, but it is not the job of guix to to manage beyond
profiles. I do think we should have transparent git HASH tagged
installs, e.g., 

guix package -i ruby --git-hash HASH

which would checkout a git tree and run something like ./pre-inst-env
under the hood.  What we do by hand now can be done automatically. But
that is a wider subject.

With regard to your emacs question, better post it with a separate
subject title. It got lost now.

Pj.

Re: Multiple versions

[Alex Kost]

Dmitry Bogatov (2015-12-27 02:02 +0300) wrote:

>   * By default, ~/.guix-profile/share/emacs/site-lisp/guix.d is not in
>     load-path. `emacs-no-x` exports no variables. So, if I install
>     some emacs library, like `emacs-f`, evaluating (require 'f) in emacs
>     fails. It is... unexpected. Is it intended behaviour?

Yes, Federico Beffa (the author of emacs-build-system) explained it here:
<http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html>

You either have to add guix.d directory manually or you can configure
emacs interface that comes with Guix, which means (require 'guix-init)
more or less.  See (info "(guix) Emacs Initial Setup") for details.

-- 
Alex

Re: Multiple versions

[Dmitry Bogatov]

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

* Pjotr Prins <pjotr.public12@thebird.nl> [2015-12-27 13:41:52+0100]
> On Sun, Dec 27, 2015 at 12:20:27PM +0300, Dmitry Bogatov wrote:
> > Currently, I am at master branch. I want install parallel-20151122.
> > But it is gone since 0877e. I propose to keep *all* versions,
> > but just 'parallel' refer to latest.
> 
> Use a combination of git hash values (to generate the versions) and
> guix profiles (to manage them at the same time).

It makes sence. The only problem is find required hash. Is it any idea
to automate it?

> > In case of haskell/python/ruby libraries, I propose keep all versions
> > multiplied by every version of compiler/interpreter.
> 
> I do the same with Ruby using profiles. I have any number of interpreters
> installed for testing and any number of libraries using either guix or
> the lib path with a profile in there.

But how do you solve problem, that for example you want library foo-999.very.new,
compiled with ruby-1.8, but they never existed at same time in guix
package tree?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple versions

[Ricardo Wurmus]

Dmitry Bogatov <KAction@gnu.org> writes:

>> I do the same with Ruby using profiles. I have any number of interpreters
>> installed for testing and any number of libraries using either guix or
>> the lib path with a profile in there.
>
> But how do you solve problem, that for example you want library foo-999.very.new,
> compiled with ruby-1.8, but they never existed at same time in guix
> package tree?

Then you can either look up the recipe for ruby-1.8 in the repository
history and copy it, or you create a fresh variant of the “ruby” package
with something like this:

    (define-public my-particular-ruby
      (package (inherit ruby)
        (version "1.8")
        (source (origin ...) ...)))

Here you adjust the version and the source, and bind this variant to a
name “my-particular-ruby”.

You can either put this expression in the “ruby.scm” module (e.g. in a
local branch), or maintain your own package module.  If you choose the
latter you’d have to tell Guix about it by pointing the environment
variable “GUIX_PACKAGE_PATH” at the path.

~~ Ricardo

Re: Multiple versions

[Pjotr Prins]

On Sun, Dec 27, 2015 at 05:40:02PM +0300, Dmitry Bogatov wrote:
> It makes sence. The only problem is find required hash. Is it any idea
> to automate it?

Not really.

> > > In case of haskell/python/ruby libraries, I propose keep all versions
> > > multiplied by every version of compiler/interpreter.
> > 
> > I do the same with Ruby using profiles. I have any number of interpreters
> > installed for testing and any number of libraries using either guix or
> > the lib path with a profile in there.
> 
> But how do you solve problem, that for example you want library foo-999.very.new,
> compiled with ruby-1.8, but they never existed at same time in guix
> package tree?

You can use source trees with GUIX_PACKAGE_PATH. Maybe you'll have to
move them to a source file. It is less hard than it looks if you are
committed to the idea.

Pj.

Re: Multiple versions

[Dmitry Bogatov]

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

> >> I do the same with Ruby using profiles. I have any number of interpreters
> >> installed for testing and any number of libraries using either guix or
> >> the lib path with a profile in there.
> >
> > But how do you solve problem, that for example you want library foo-999.very.new,
> > compiled with ruby-1.8, but they never existed at same time in guix
> > package tree?
> 
> Then you can either look up the recipe for ruby-1.8 in the repository
> history and copy it, or you create a fresh variant of the “ruby” package
> with something like this:
> 
>     (define-public my-particular-ruby
>       (package (inherit ruby)
>         (version "1.8")
>         (source (origin ...) ...)))
> 
> Here you adjust the version and the source, and bind this variant to a
> name “my-particular-ruby”.
> 
> You can either put this expression in the “ruby.scm” module (e.g. in a
> local branch), or maintain your own package module.  If you choose the
> latter you’d have to tell Guix about it by pointing the environment
> variable “GUIX_PACKAGE_PATH” at the path.

Looks not so easy, but I got my answers. Thanks.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Emacs load path (was: Re: Multiple versions)

[Dmitry Bogatov]

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

* Alex Kost <alezost@gmail.com> [2015-12-27 17:11:20+0300]
> Dmitry Bogatov (2015-12-27 02:02 +0300) wrote:
> 
> >   * By default, ~/.guix-profile/share/emacs/site-lisp/guix.d is not in
> >     load-path. `emacs-no-x` exports no variables. So, if I install
> >     some emacs library, like `emacs-f`, evaluating (require 'f) in emacs
> >     fails. It is... unexpected. Is it intended behaviour?
> 
> Yes, Federico Beffa (the author of emacs-build-system) explained it here:
> <http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html>
> 
> You either have to add guix.d directory manually or you can configure
> emacs interface that comes with Guix, which means (require 'guix-init)
> more or less.  See (info "(guix) Emacs Initial Setup") for details.

Read this email. It explain existance of guix.d subdirectory, but why
can't we force emacs to execute following pseudo-code at start:

(for dir in "${HOME}.guix-profile/share/emacs/site-lisp/guix.d"
  (push dir load-path))

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs load path

[Alex Kost]

Dmitry Bogatov (2015-12-27 19:47 +0300) wrote:

> * Alex Kost <alezost@gmail.com> [2015-12-27 17:11:20+0300]
>> Dmitry Bogatov (2015-12-27 02:02 +0300) wrote:
>>
>> >   * By default, ~/.guix-profile/share/emacs/site-lisp/guix.d is not in
>> >     load-path. `emacs-no-x` exports no variables. So, if I install
>> >     some emacs library, like `emacs-f`, evaluating (require 'f) in emacs
>> >     fails. It is... unexpected. Is it intended behaviour?
>>
>> Yes, Federico Beffa (the author of emacs-build-system) explained it here:
>> <http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html>
>>
>> You either have to add guix.d directory manually or you can configure
>> emacs interface that comes with Guix, which means (require 'guix-init)
>> more or less.  See (info "(guix) Emacs Initial Setup") for details.
>
> Read this email. It explain existance of guix.d subdirectory, but why
> can't we force emacs to execute following pseudo-code at start:
>
> (for dir in "${HOME}.guix-profile/share/emacs/site-lisp/guix.d"
>   (push dir load-path))

This is more or less what (require 'guix-init) does (among other
things).  And it works out of the box on GuixSD.

--
Alex

Re: Emacs load path

[Alex Kost]

Federico Beffa (2015-12-28 01:16 +0300) wrote:

[...]
> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))

This is very unusual.  Why 'append' instead of 'cons'?  Anyway an
idiomatic way is: (add-to-list 'load-path "dir")

-- 
Alex

Re: Emacs load path

[Taylan Ulrich Bayırlı/Kammer]

Alex Kost <alezost@gmail.com> writes:

> Federico Beffa (2015-12-28 01:16 +0300) wrote:
>
> [...]
>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>
> This is very unusual.  Why 'append' instead of 'cons'?  Anyway an
> idiomatic way is: (add-to-list 'load-path "dir")

If it's important to add the new element to the end of the list, then
one can also tell that to 'add-to-list' via an optional Boolean
argument, like:

    (add-to-list 'load-path "dir" t)

Taylan

Re: Multiple versions

[Ludovic Courtès]

Dmitry Bogatov <KAction@gnu.org> skribis:

> Currently, I am at master branch. I want install parallel-20151122.
> But it is gone since 0877e. I propose to keep *all* versions,
> but just 'parallel' refer to latest.

First, I think it’s important to distinguish the source (the package
recipes in gnu/packages/*.scm) and the installed packages (stuff in
/gnu/store.)

Users can keep the versions they want in their store and in their
profiles.

For recipes, as Andreas noted, it would be terrible for Guix as a
project to provide and maintain zillions of different versions of each
package (keeping them all would be easy, but we want to provide packages
that actually build :-)).

However, users can write their own modules containing different versions
or variants of the packages.  For instance, you could write:

  (define-module (my-packages)
    #:use-module (gnu packages parallel))

  (define my-parallel
    ;; Inherit from the Parallel recipe that Guix provides, but override
    ;; the version being used.
    (package
      (inherit parallel)
      (version "x.y.z")
      (source (origin
                (method url-fetch)
                (uri (string-append "mirror://gnu/parallel/parallel-"
                                    version ".tar.bz2"))
                (sha256
                 (base32
                  "0phn9dlkqlq3cq468ypxbbn78bsjcin743pyvf8ip4qg6jz662jm"))))))

Then drop that in ‘GUIX_PACKAGE_PATH’, and run:

  guix package -i parallel-x.y.z

HTH,
Ludo’.

Re: Emacs load path

[Federico Beffa]

On Mon, Dec 28, 2015 at 11:15 PM, Alex Kost <alezost@gmail.com> wrote:
> Federico Beffa (2015-12-28 01:16 +0300) wrote:
>
> [...]
>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>
> This is very unusual.  Why 'append' instead of 'cons'?  Anyway an
> idiomatic way is: (add-to-list 'load-path "dir")

Alex, this isn't useful. Obviously it's coming from my .emacs file
where I add more than one directory... But this is looking at trees
for the forest...

A useful approach would be to fix the problem such that if a user
installs emacs with guix the above steps happen automatically without
any user intervention.

Fede

Re: Emacs load path

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> If you install guix in the default prefix (/usr/local) you should find a
> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
> you can include the following commands in your .emacs file and you
> should be all set:
>
> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
> 2. (require 'guix-init nil t)
>
> On some host distros step 1. may not even be needed.

I don’t see how to make that happen automatically on foreign distros.
Any ideas?

We still have the option of making it more prominent in the
documentation, for example by mentioning specifically Emacs under
<https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.

Thoughts?

Ludo’.

Re: Emacs load path

[Federico Beffa]

On Wed, Dec 30, 2015 at 5:29 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> If you install guix in the default prefix (/usr/local) you should find a
>> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
>> you can include the following commands in your .emacs file and you
>> should be all set:
>>
>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>> 2. (require 'guix-init nil t)
>>
>> On some host distros step 1. may not even be needed.
>
> I don’t see how to make that happen automatically on foreign distros.
> Any ideas?
>
> We still have the option of making it more prominent in the
> documentation, for example by mentioning specifically Emacs under
> <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.
>
> Thoughts?

If we make an 'emacs-guix' package and make it an input to emacs it should work.

Regards,
Fede

Re: Emacs load path

[Alex Kost]

Federico Beffa (2015-12-30 15:16 +0300) wrote:

> On Mon, Dec 28, 2015 at 11:15 PM, Alex Kost <alezost@gmail.com> wrote:
>> Federico Beffa (2015-12-28 01:16 +0300) wrote:
>>
>> [...]
>>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>>
>> This is very unusual.  Why 'append' instead of 'cons'?  Anyway an
>> idiomatic way is: (add-to-list 'load-path "dir")
>
> Alex, this isn't useful. Obviously it's coming from my .emacs file
> where I add more than one directory... But this is looking at trees
> for the forest...

Thanks for clarifying.  I said it's unusual, because in this example you
added just a *single* directory.  After sending the message I guessed
that you probably uses it for adding several elements to the list (I do
absolutely the same for `auto-mode-alist' variable).

> A useful approach would be to fix the problem such that if a user
> installs emacs with guix the above steps happen automatically without
> any user intervention.

Yeah, it would probably be a good default, but only if this default can
be changed.  I mean if I didn't install emacs packages with guix, I would
like to avoid loading an additional code for that.  In GuixSD I can do
it with "export EMACSLOADPATH=", so if our Emacs package will somehow
"automagically" look at "~/.guix-profile/share/emacs/site-lisp/guix.d/…"
directories, I want to have a way to disable this feature.

-- 
Alex

Re: Emacs load path

[Federico Beffa]

On Wed, Dec 30, 2015 at 7:55 PM, Alex Kost <alezost@gmail.com> wrote:
>> A useful approach would be to fix the problem such that if a user
>> installs emacs with guix the above steps happen automatically without
>> any user intervention.
>
> Yeah, it would probably be a good default, but only if this default can
> be changed.  I mean if I didn't install emacs packages with guix, I would
> like to avoid loading an additional code for that.  In GuixSD I can do
> it with "export EMACSLOADPATH=", so if our Emacs package will somehow
> "automagically" look at "~/.guix-profile/share/emacs/site-lisp/guix.d/…"
> directories, I want to have a way to disable this feature.

I would mimic the emacs package system: The packages are loaded after
loading the init file. To disable automatic package loading, you can
change the variable ‘package-enable-at-startup’ to ‘nil’.

Regards,
Fede

Re: Emacs load path

[Alex Kost]

Federico Beffa (2015-12-31 01:18 +0300) wrote:

> On Wed, Dec 30, 2015 at 7:55 PM, Alex Kost <alezost@gmail.com> wrote:
>>> A useful approach would be to fix the problem such that if a user
>>> installs emacs with guix the above steps happen automatically without
>>> any user intervention.
>>
>> Yeah, it would probably be a good default, but only if this default can
>> be changed.  I mean if I didn't install emacs packages with guix, I would
>> like to avoid loading an additional code for that.  In GuixSD I can do
>> it with "export EMACSLOADPATH=", so if our Emacs package will somehow
>> "automagically" look at "~/.guix-profile/share/emacs/site-lisp/guix.d/…"
>> directories, I want to have a way to disable this feature.
>
> I would mimic the emacs package system: The packages are loaded after
> loading the init file. To disable automatic package loading, you can
> change the variable ‘package-enable-at-startup’ to ‘nil’.

This is already mimic-ed: there is ‘guix-package-enable-at-startup’
variable for the same purpose.  But on GuixSD, (require 'guix-init) is
performed before user config is loaded, so as I said, you need to use
"export EMACSLOADPATH=" to prevent this additional stuff from loading.

BTW I heard (but didn't check) that in emacs 25.1, packages (installed
using emacs package system (package.el)) will be enabled before loading
the init file, so you can't avoid it if you wish.  If it is so (I should
better check before blaming), then it is an anti-feature for me.

-- 
Alex

Re: Emacs load path

[Federico Beffa]

On Thu, Dec 31, 2015 at 10:02 AM, Alex Kost <alezost@gmail.com> wrote:
>> I would mimic the emacs package system: The packages are loaded after
>> loading the init file. To disable automatic package loading, you can
>> change the variable ‘package-enable-at-startup’ to ‘nil’.
>
> This is already mimic-ed: there is ‘guix-package-enable-at-startup’
> variable for the same purpose.  But on GuixSD, (require 'guix-init) is
> performed before user config is loaded, so as I said, you need to use
> "export EMACSLOADPATH=" to prevent this additional stuff from loading.

Instead of a (require 'guix-init) before loading the init file you
could just load a tiny amount of code whose purpose is only to decide
if 'guix-init' should be loaded after processing the init file.

Fede

Re: Emacs load path

[Alex Kost]

Federico Beffa (2015-12-31 12:27 +0300) wrote:

> On Thu, Dec 31, 2015 at 10:02 AM, Alex Kost <alezost@gmail.com> wrote:
>>> I would mimic the emacs package system: The packages are loaded after
>>> loading the init file. To disable automatic package loading, you can
>>> change the variable ‘package-enable-at-startup’ to ‘nil’.
>>
>> This is already mimic-ed: there is ‘guix-package-enable-at-startup’
>> variable for the same purpose.  But on GuixSD, (require 'guix-init) is
>> performed before user config is loaded, so as I said, you need to use
>> "export EMACSLOADPATH=" to prevent this additional stuff from loading.
>
> Instead of a (require 'guix-init) before loading the init file you
> could just load a tiny amount of code whose purpose is only to decide
> if 'guix-init' should be loaded after processing the init file.

Sorry, I think I lost the thread of what we are talking about.  Is it a
suggestion for "/etc/emacs/site-start.el" that is generated in GuixSD?

-- 
Alex

Re: Emacs load path

[Alex Kost]

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

Ludovic Courtès (2015-12-30 19:29 +0300) wrote:

> Federico Beffa <beffa@ieee.org> skribis:
>
>> If you install guix in the default prefix (/usr/local) you should find a
>> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
>> you can include the following commands in your .emacs file and you
>> should be all set:
>>
>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>> 2. (require 'guix-init nil t)
>>
>> On some host distros step 1. may not even be needed.
>
> I don’t see how to make that happen automatically on foreign distros.
> Any ideas?

No ideas.

> We still have the option of making it more prominent in the
> documentation, for example by mentioning specifically Emacs under
> <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.

I also think we should mention Emacs packages in the manual.  What about
the attached patch?


[-- Attachment #2: 0001-doc-Describe-how-to-configure-Emacs-packages.patch --]
[-- Type: text/x-patch, Size: 1949 bytes --]

From 938e45e104b55b32d6c2423543c18efc7dc9365a Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Fri, 1 Jan 2016 01:37:45 +0300
Subject: [PATCH] doc: Describe how to configure Emacs packages.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by Ludovic Courtès <ludo@gnu.org>.

* doc/guix.texi (Application Setup)[Emacs Packages]: New subsection.
---
 doc/guix.texi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index c45f1c8..a8cdac8 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1035,6 +1035,31 @@ for Chinese languages:
 guix package -i font-adobe-source-han-sans:cn
 @end example
 
+@subsection Emacs Packages
+
+When you install Emacs packages with Guix, the elisp files may be placed
+either in @file{$HOME/.guix-profile/share/emacs/site-lisp/} or in
+sub-directories of
+@file{$HOME/.guix-profile/share/emacs/site-lisp/guix.d/}.  The latter
+directory exists because potentially there may exist thousands of Emacs
+packages and storing all their files in a single directory may be not
+reliable (because of name conflicts).  So we think using a separate
+directory for each package is a good idea.  It is very similar to how
+Emacs package system organizes the file structure (@pxref{Package
+Files,,, emacs, The GNU Emacs Manual}).
+
+So, to let Emacs ``know'' where these package are placed (i.e., to add
+required directories to @code{load-path} and to load
+@file{@dots{}-autoloads.el} files), you can set up the elisp code that
+comes with Guix.  It should look like this:
+
+@example
+(add-to-list 'load-path "/path/to/guix-emacs-directory")
+(require 'guix-init nil t)
+@end example
+
+@xref{Emacs Initial Setup}, for more information.
+
 @c TODO What else?
 
 @c *********************************************************************
-- 
2.6.3

Re: Emacs load path

[Federico Beffa]

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

On Wed, Dec 30, 2015 at 5:55 PM, Federico Beffa <beffa@ieee.org> wrote:
> On Wed, Dec 30, 2015 at 5:29 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> If you install guix in the default prefix (/usr/local) you should find a
>>> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
>>> you can include the following commands in your .emacs file and you
>>> should be all set:
>>>
>>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>>> 2. (require 'guix-init nil t)
>>>
>>> On some host distros step 1. may not even be needed.
>>
>> I don’t see how to make that happen automatically on foreign distros.
>> Any ideas?
>>
>> We still have the option of making it more prominent in the
>> documentation, for example by mentioning specifically Emacs under
>> <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.
>>
>> Thoughts?
>
> If we make an 'emacs-guix' package and make it an input to emacs it should work.

Attached is a proof of concept patch showing one way to do it.

If you don't want to add the full 'guix.el', then we should definitely
add code in a similar way to instruct emacs to look in the right
places (".../guix.d") for our emacs packages out of the box.  As
Dmitry rightfully points out, having emacs packages which do not work
out of the box is just a bug.

Regards,
Fede

[-- Attachment #2: 0001-gnu-emacs-Add-guix.el-functionality.patch --]
[-- Type: text/x-diff, Size: 3044 bytes --]

From cb2a13f06c80d3b53451d15b5441cdc267666083 Mon Sep 17 00:00:00 2001
From: Federico Beffa <beffa@fbengineering.ch>
Date: Fri, 1 Jan 2016 15:12:40 +0100
Subject: [PATCH] gnu: emacs: Add guix.el functionality.

* gnu/packages/emacs.scm (emacs): Convert to 'modify-phases' syntax.  Add
  'guix-src' input and 'install-guix-el phase.
---
 gnu/packages/emacs.scm | 38 +++++++++++++++++++++++++++++---------
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 4b23a54..739eed1 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -56,6 +56,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages acl)
+  #:use-module (gnu packages package-management)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pdf)
   #:use-module (gnu packages scheme)
@@ -78,14 +79,32 @@
              (patches (list (search-patch "emacs-exec-path.patch")))))
     (build-system glib-or-gtk-build-system)
     (arguments
-     '(#:phases (alist-cons-before
-                 'configure 'fix-/bin/pwd
-                 (lambda _
-                   ;; Use `pwd', not `/bin/pwd'.
-                   (substitute* (find-files "." "^Makefile\\.in$")
-                     (("/bin/pwd")
-                      "pwd")))
-                 %standard-phases)))
+     `(#:modules ((guix build glib-or-gtk-build-system)
+                  (guix build utils)
+                  (srfi srfi-26))
+       #:phases
+       (modify-phases %standard-phases
+         (add-before 'configure 'fix-/bin/pwd
+           (lambda _
+             ;; Use `pwd', not `/bin/pwd'.
+             (substitute* (find-files "." "^Makefile\\.in$")
+               (("/bin/pwd")
+                "pwd"))))
+         (add-after 'install 'install-guix-el
+             (lambda* (#:key inputs outputs #:allow-other-keys)
+               (let* ((guix-src (assoc-ref inputs "guix-src"))
+                      (out (assoc-ref outputs "out"))
+                      (site-lisp (string-append out "/share/emacs/"
+                                                ,(version-major+minor version)
+                                                "/site-lisp"))
+                      (unpack (assoc-ref %standard-phases 'unpack)))
+                 (mkdir "guix")
+                 (with-directory-excursion "guix"
+                   (apply unpack (list #:source guix-src))
+                   ;; FIXME: configure and byte-compile guix.el before installing
+                   (for-each (cut install-file <> site-lisp)
+                             (find-files "emacs" "\\.el")))
+                 #t))))))
     (inputs
      `(("gnutls" ,gnutls)
        ("ncurses" ,ncurses)
@@ -110,7 +129,8 @@
        ("libice" ,libice)
        ("libsm" ,libsm)
        ("alsa-lib" ,alsa-lib)
-       ("dbus" ,dbus)))
+       ("dbus" ,dbus)
+       ("guix-src" ,(package-source guix))))
     (native-inputs
      `(("pkg-config" ,pkg-config)
        ("texinfo" ,texinfo)))
-- 
2.6.3

Re: Emacs load path

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Wed, Dec 30, 2015 at 5:55 PM, Federico Beffa <beffa@ieee.org> wrote:
>> On Wed, Dec 30, 2015 at 5:29 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> If you install guix in the default prefix (/usr/local) you should find a
>>>> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
>>>> you can include the following commands in your .emacs file and you
>>>> should be all set:
>>>>
>>>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>>>> 2. (require 'guix-init nil t)
>>>>
>>>> On some host distros step 1. may not even be needed.
>>>
>>> I don’t see how to make that happen automatically on foreign distros.
>>> Any ideas?
>>>
>>> We still have the option of making it more prominent in the
>>> documentation, for example by mentioning specifically Emacs under
>>> <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.
>>>
>>> Thoughts?
>>
>> If we make an 'emacs-guix' package and make it an input to emacs it should work.
>
> Attached is a proof of concept patch showing one way to do it.
>
> If you don't want to add the full 'guix.el',

Indeed, I think it would be too much.

> then we should definitely add code in a similar way to instruct emacs
> to look in the right places (".../guix.d") for our emacs packages out
> of the box.  As Dmitry rightfully points out, having emacs packages
> which do not work out of the box is just a bug.

Yeah.  Alex, any idea how to add the guix.d subdirectories to the search
path without duplicating all of guix.el in the ‘emacs’ package?

Thanks,
Ludo’.

Re: Emacs load path

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> From 938e45e104b55b32d6c2423543c18efc7dc9365a Mon Sep 17 00:00:00 2001
> From: Alex Kost <alezost@gmail.com>
> Date: Fri, 1 Jan 2016 01:37:45 +0300
> Subject: [PATCH] doc: Describe how to configure Emacs packages.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Suggested by Ludovic Courtès <ludo@gnu.org>.
>
> * doc/guix.texi (Application Setup)[Emacs Packages]: New subsection.

This LGTM.

I would still like to see if we can find an automatic way to address the
issue, as suggested by Federico, which would make this section less
useful.

Thoughts?

Ludo’.

Re: Emacs load path

[Alex Kost]

Federico Beffa (2016-01-01 17:25 +0300) wrote:

> On Wed, Dec 30, 2015 at 5:55 PM, Federico Beffa <beffa@ieee.org> wrote:
>> On Wed, Dec 30, 2015 at 5:29 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> If you install guix in the default prefix (/usr/local) you should find a
>>>> file called 'guix.el' in /usr/local/share/emacs/site-lisp/.  With that
>>>> you can include the following commands in your .emacs file and you
>>>> should be all set:
>>>>
>>>> 1. (setq load-path (append '("/usr/local/share/emacs/site-lisp/") load-path))
>>>> 2. (require 'guix-init nil t)
>>>>
>>>> On some host distros step 1. may not even be needed.
>>>
>>> I don’t see how to make that happen automatically on foreign distros.
>>> Any ideas?
>>>
>>> We still have the option of making it more prominent in the
>>> documentation, for example by mentioning specifically Emacs under
>>> <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.
>>>
>>> Thoughts?
>>
>> If we make an 'emacs-guix' package and make it an input to emacs it should work.
>
> Attached is a proof of concept patch showing one way to do it.
>
> If you don't want to add the full 'guix.el', then we should definitely
> add code in a similar way to instruct emacs to look in the right
> places (".../guix.d") for our emacs packages out of the box.  As
> Dmitry rightfully points out, having emacs packages which do not work
> out of the box is just a bug.

Not for me!  As a user, I always want to have pure upstream packages if
possible, without unnecessary modifications made by package maintainers.
Such modifications have an intention to make users life easier, but in
fact they are often a pain that I'd like to get rid of.  I only talk
about my own experience (most of the times I'm for simplicity and
against "full-feature"-ness).

[...]
> @@ -78,14 +79,32 @@
>               (patches (list (search-patch "emacs-exec-path.patch")))))
>      (build-system glib-or-gtk-build-system)
>      (arguments
> -     '(#:phases (alist-cons-before
> -                 'configure 'fix-/bin/pwd
> -                 (lambda _
> -                   ;; Use `pwd', not `/bin/pwd'.
> -                   (substitute* (find-files "." "^Makefile\\.in$")
> -                     (("/bin/pwd")
> -                      "pwd")))
> -                 %standard-phases)))
> +     `(#:modules ((guix build glib-or-gtk-build-system)
> +                  (guix build utils)
> +                  (srfi srfi-26))
> +       #:phases
> +       (modify-phases %standard-phases
> +         (add-before 'configure 'fix-/bin/pwd
> +           (lambda _
> +             ;; Use `pwd', not `/bin/pwd'.
> +             (substitute* (find-files "." "^Makefile\\.in$")
> +               (("/bin/pwd")
> +                "pwd"))))
> +         (add-after 'install 'install-guix-el
> +             (lambda* (#:key inputs outputs #:allow-other-keys)
> +               (let* ((guix-src (assoc-ref inputs "guix-src"))
> +                      (out (assoc-ref outputs "out"))
> +                      (site-lisp (string-append out "/share/emacs/"
> +                                                ,(version-major+minor version)
> +                                                "/site-lisp"))
> +                      (unpack (assoc-ref %standard-phases 'unpack)))
> +                 (mkdir "guix")
> +                 (with-directory-excursion "guix"
> +                   (apply unpack (list #:source guix-src))
> +                   ;; FIXME: configure and byte-compile guix.el before installing
> +                   (for-each (cut install-file <> site-lisp)
> +                             (find-files "emacs" "\\.el")))
> +                 #t))))))

Sorry, I didn't try it, but IIUC this just adds guix elisp files to a
site-lisp directory, right?
But a user still have to use (require 'guix-init), so this shouldn't
work out of the box, or do I miss anything?

-- 
Alex

Re: Emacs load path

[Alex Kost]

Ludovic Courtès (2016-01-01 18:22 +0300) wrote:

>> then we should definitely add code in a similar way to instruct emacs
>> to look in the right places (".../guix.d") for our emacs packages out
>> of the box.  As Dmitry rightfully points out, having emacs packages
>> which do not work out of the box is just a bug.
>
> Yeah.  Alex, any idea how to add the guix.d subdirectories to the search
> path without duplicating all of guix.el in the ‘emacs’ package?

Yeah, no need to duplicate all of the guix elisp files.  Only
"guix-emacs.el" (and its dependencies: "guix-profiles.el" and
"guix-config.el") is needed.  And instead of (require 'guix-init) the
following code should be used to "activate" our .guix.d directories:

(when (require 'guix-emacs nil t)
  (guix-emacs-load-autoloads))

-- 
Alex

Re: Emacs load path

[Federico Beffa]

On Fri, Jan 1, 2016 at 5:28 PM, Alex Kost <alezost@gmail.com> wrote:
> Ludovic Courtès (2016-01-01 18:22 +0300) wrote:
>
>>> then we should definitely add code in a similar way to instruct emacs
>>> to look in the right places (".../guix.d") for our emacs packages out
>>> of the box.  As Dmitry rightfully points out, having emacs packages
>>> which do not work out of the box is just a bug.
>>
>> Yeah.  Alex, any idea how to add the guix.d subdirectories to the search
>> path without duplicating all of guix.el in the ‘emacs’ package?
>
> Yeah, no need to duplicate all of the guix elisp files.  Only
> "guix-emacs.el" (and its dependencies: "guix-profiles.el" and
> "guix-config.el") is needed.  And instead of (require 'guix-init) the
> following code should be used to "activate" our .guix.d directories:

there's no 'guix-config.el', but only 'guix-config.el.in'. It would be
great if you could provide a working patch.

Thanks,
Fede

Re: Emacs load path

[Alex Kost]

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

Federico Beffa (2016-01-01 19:53 +0300) wrote:

> On Fri, Jan 1, 2016 at 5:28 PM, Alex Kost <alezost@gmail.com> wrote:
>> Ludovic Courtès (2016-01-01 18:22 +0300) wrote:
>>
>>>> then we should definitely add code in a similar way to instruct emacs
>>>> to look in the right places (".../guix.d") for our emacs packages out
>>>> of the box.  As Dmitry rightfully points out, having emacs packages
>>>> which do not work out of the box is just a bug.
>>>
>>> Yeah.  Alex, any idea how to add the guix.d subdirectories to the search
>>> path without duplicating all of guix.el in the ‘emacs’ package?
>>
>> Yeah, no need to duplicate all of the guix elisp files.  Only
>> "guix-emacs.el" (and its dependencies: "guix-profiles.el" and
>> "guix-config.el") is needed.  And instead of (require 'guix-init) the
>> following code should be used to "activate" our .guix.d directories:
>
> there's no 'guix-config.el', but only 'guix-config.el.in'. It would be
> great if you could provide a working patch.

Hm, OK, so your "proof of concept patch" will have the same problem.
Could you please answer
<http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00021.html>, as
I still don't understand how your suggestion can help Emacs to find
packages in "guix.d" dirs of user profile.  To make this work out of the
box, Emacs should load some additional code (see below), but what you
suggest is just adding guix-...el files ("guix-emacs.el" now should be
enough) to Emacs site-lisp directory.

Returning to 'guix-config' problem, we can make a "soft" dependency on
'guix-profiles' (see the attached patch), so the only file needed for
finding emacs packages in "guix.d" will be "guix-emacs.el".  And the
code that should be loaded by Emacs to find guix emacs packages will be:

(when (require 'guix-emacs nil t)
  (add-to-list 'load-path (guix-emacs-directory))
  (guix-emacs-load-autoloads))


[-- Attachment #2: 0001-emacs-Make-guix-emacs.el-independent.patch --]
[-- Type: text/x-patch, Size: 2011 bytes --]

From 62d94b2e7253334f00251922c62c3fd700fd1e52 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Sat, 2 Jan 2016 16:52:39 +0300
Subject: [PATCH] emacs: Make "guix-emacs.el" independent.

"guix-emacs.el" may be used just for "instructing" Emacs where to find
Emacs packages installed with Guix, so it should have as minimal
dependencies as possible.

See <http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00022.html>.

* emacs/guix-emacs.el: Require 'guix-profiles' optionally.
  (guix-emacs-load-autoloads): Use 'guix-profile-prompt' only if it is
  available.
---
 emacs/guix-emacs.el | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/emacs/guix-emacs.el b/emacs/guix-emacs.el
index 2f809ed..311ab33 100644
--- a/emacs/guix-emacs.el
+++ b/emacs/guix-emacs.el
@@ -1,6 +1,6 @@
 ;;; guix-emacs.el --- Emacs packages installed with Guix
 
-;; Copyright © 2014 Alex Kost <alezost@gmail.com>
+;; Copyright © 2014, 2015, 2016 Alex Kost <alezost@gmail.com>
 
 ;; This file is part of GNU Guix.
 
@@ -24,8 +24,9 @@
 
 ;;; Code:
 
-(require 'guix-profiles)
 (require 'cl-lib)
+(unless (require 'guix-profiles nil t)
+  (defvar guix-user-profile (expand-file-name "~/.guix-profile")))
 
 (defcustom guix-emacs-activate-after-operation t
   "Activate Emacs packages after installing.
@@ -90,7 +91,9 @@ Return nil if there are no emacs packages installed in PROFILE."
   "Load autoloads for Emacs packages installed in PROFILE.
 If PROFILE is nil, use `guix-user-profile'.
 Add autoloads directories to `load-path'."
-  (interactive (list (guix-profile-prompt)))
+  (interactive (list (if (fboundp 'guix-profile-prompt)
+                         (funcall 'guix-profile-prompt)
+                       guix-user-profile)))
   (let* ((autoloads     (guix-emacs-find-autoloads profile))
          (new-autoloads (cl-nset-difference autoloads
                                             guix-emacs-autoloads
-- 
2.6.3

Re: Emacs load path

[Federico Beffa]

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

On Sat, Jan 2, 2016 at 3:13 PM, Alex Kost <alezost@gmail.com> wrote:
> Federico Beffa (2016-01-01 19:53 +0300) wrote:
>
>> On Fri, Jan 1, 2016 at 5:28 PM, Alex Kost <alezost@gmail.com> wrote:
>>> Ludovic Courtès (2016-01-01 18:22 +0300) wrote:
>>>
>>>>> then we should definitely add code in a similar way to instruct emacs
>>>>> to look in the right places (".../guix.d") for our emacs packages out
>>>>> of the box.  As Dmitry rightfully points out, having emacs packages
>>>>> which do not work out of the box is just a bug.
>>>>
>>>> Yeah.  Alex, any idea how to add the guix.d subdirectories to the search
>>>> path without duplicating all of guix.el in the ‘emacs’ package?
>>>
>>> Yeah, no need to duplicate all of the guix elisp files.  Only
>>> "guix-emacs.el" (and its dependencies: "guix-profiles.el" and
>>> "guix-config.el") is needed.  And instead of (require 'guix-init) the
>>> following code should be used to "activate" our .guix.d directories:
>>
>> there's no 'guix-config.el', but only 'guix-config.el.in'. It would be
>> great if you could provide a working patch.
>
> Hm, OK, so your "proof of concept patch" will have the same problem.
> Could you please answer
> <http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00021.html>, as
> I still don't understand how your suggestion can help Emacs to find
> packages in "guix.d" dirs of user profile.

That's the easy part. Once we know how to load a minimal version of
your code, we add it to 'site-start.el'. Emacs automatically loads it.

> Returning to 'guix-config' problem, we can make a "soft" dependency on
> 'guix-profiles' (see the attached patch), so the only file needed for
> finding emacs packages in "guix.d" will be "guix-emacs.el".  And the
> code that should be loaded by Emacs to find guix emacs packages will be:
>
> (when (require 'guix-emacs nil t)
>   (add-to-list 'load-path (guix-emacs-directory))
>   (guix-emacs-load-autoloads))
>

I've done this, but it doesn't load as 'guix-config' is missing. I
guess it needs your patch which I didn't try.

Fede

[-- Attachment #2: 0001-gnu-emacs-Add-guix.d-directories-to-load-path.patch --]
[-- Type: text/x-diff, Size: 3573 bytes --]

From 5d1ada998bdb8755845914d28757d142ed8de8bf Mon Sep 17 00:00:00 2001
From: Federico Beffa <beffa@fbengineering.ch>
Date: Fri, 1 Jan 2016 15:12:40 +0100
Subject: [PATCH] gnu: emacs: Add 'guix.d' directories to 'load-path'.

* gnu/packages/emacs.scm (emacs): Convert to 'modify-phases' syntax.  Add
  'guix-src' input and 'install-guix-emacs phase.
---
 gnu/packages/emacs.scm | 48 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index eb50b52..9b8b7cf 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -56,6 +56,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages acl)
+  #:use-module (gnu packages package-management)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pdf)
   #:use-module (gnu packages scheme)
@@ -78,14 +79,42 @@
              (patches (list (search-patch "emacs-exec-path.patch")))))
     (build-system glib-or-gtk-build-system)
     (arguments
-     '(#:phases (alist-cons-before
-                 'configure 'fix-/bin/pwd
-                 (lambda _
-                   ;; Use `pwd', not `/bin/pwd'.
-                   (substitute* (find-files "." "^Makefile\\.in$")
-                     (("/bin/pwd")
-                      "pwd")))
-                 %standard-phases)))
+     `(#:modules ((guix build glib-or-gtk-build-system)
+                  (guix build utils)
+                  (srfi srfi-26))
+       #:phases
+       (modify-phases %standard-phases
+         (add-before 'configure 'fix-/bin/pwd
+           (lambda _
+             ;; Use `pwd', not `/bin/pwd'.
+             (substitute* (find-files "." "^Makefile\\.in$")
+               (("/bin/pwd")
+                "pwd"))))
+         (add-after 'install 'install-guix-emacs
+             (lambda* (#:key inputs outputs #:allow-other-keys)
+               (let* ((guix-src (assoc-ref inputs "guix-src"))
+                      (out (assoc-ref outputs "out"))
+                      (site-lisp (string-append out "/share/emacs/"
+                                                ,(version-major+minor version)
+                                                "/site-lisp"))
+                      (unpack (assoc-ref %standard-phases 'unpack)))
+                 (mkdir "guix")
+                 (with-directory-excursion "guix"
+                   (apply unpack (list #:source guix-src))
+                   ;; FIXME: miss cl-lib
+                   (install-file "emacs/guix-emacs.el" site-lisp))
+                 (with-directory-excursion site-lisp
+                   (with-output-to-file "site-start.el"
+                     (lambda ()
+                       (display "(when (require 'guix-emacs nil t)
+  (add-to-list 'load-path (guix-emacs-directory))
+  (guix-emacs-load-autoloads))"))))
+                 (zero?
+                  (let ((expr `(byte-recompile-directory
+                                (file-name-as-directory ,site-lisp) 0)))
+                    (system*
+                     (string-append out "/bin/emacs") "--quick" "--batch"
+                     (format #f "--eval=~S" expr))))))))))
     (inputs
      `(("gnutls" ,gnutls)
        ("ncurses" ,ncurses)
@@ -110,7 +139,8 @@
        ("libice" ,libice)
        ("libsm" ,libsm)
        ("alsa-lib" ,alsa-lib)
-       ("dbus" ,dbus)))
+       ("dbus" ,dbus)
+       ("guix-src" ,(package-source guix))))
     (native-inputs
      `(("pkg-config" ,pkg-config)
        ("texinfo" ,texinfo)))
-- 
2.6.3

Re: Emacs load path

[Alex Kost]

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

Federico Beffa (2016-01-04 13:18 +0300) wrote:

> On Sat, Jan 2, 2016 at 3:13 PM, Alex Kost <alezost@gmail.com> wrote:
>> Federico Beffa (2016-01-01 19:53 +0300) wrote:
[...]
>>> there's no 'guix-config.el', but only 'guix-config.el.in'. It would be
>>> great if you could provide a working patch.
>>
>> Hm, OK, so your "proof of concept patch" will have the same problem.
>> Could you please answer
>> <http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00021.html>, as
>> I still don't understand how your suggestion can help Emacs to find
>> packages in "guix.d" dirs of user profile.
>
> That's the easy part. Once we know how to load a minimal version of
> your code, we add it to 'site-start.el'. Emacs automatically loads it.

Ah, now I see what you mean, thanks!  And emacs can be started with
"--no-site-file" so my concerns about avoiding this are fulfilled.  For
simplicity, we can even add "site-start.el" to the guix repo I think.

>> Returning to 'guix-config' problem, we can make a "soft" dependency on
>> 'guix-profiles' (see the attached patch), so the only file needed for
>> finding emacs packages in "guix.d" will be "guix-emacs.el".  And the
>> code that should be loaded by Emacs to find guix emacs packages will be:
>>
>> (when (require 'guix-emacs nil t)
>>   (add-to-list 'load-path (guix-emacs-directory))
>>   (guix-emacs-load-autoloads))
>
> I've done this, but it doesn't load as 'guix-config' is missing. I
> guess it needs your patch which I didn't try.

Yes, it meant to be used with the patch.

So IIUC we need the following patches to make our Emacs find packages in
a user profile:

- patch for stripping "guix-emacs.el" from extra dependencies (attached
  to the previous message);

- patch for adding "site-start.el" (attached to this message);

- modified version of your patch to copy "site-start.el" and
  "guix-emacs.el" to the proper places.


[-- Attachment #2: 0001-emacs-Add-site-start.el.patch --]
[-- Type: text/x-patch, Size: 1340 bytes --]

From dcc0497afa74f5c614d086773a86615b546c0448 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Tue, 5 Jan 2016 12:29:53 +0300
Subject: [PATCH] emacs: Add "site-start.el".

* emacs/site-start.el: New file.
* emacs.am (ELFILES): Add it.
---
 emacs.am            | 5 +++--
 emacs/site-start.el | 4 ++++
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 emacs/site-start.el

diff --git a/emacs.am b/emacs.am
index 85165b9..dcccb44 100644
--- a/emacs.am
+++ b/emacs.am
@@ -1,5 +1,5 @@
 # GNU Guix --- Functional package management for GNU
-# Copyright © 2014, 2015 Alex Kost <alezost@gmail.com>
+# Copyright © 2014, 2015, 2016 Alex Kost <alezost@gmail.com>
 #
 # This file is part of GNU Guix.
 #
@@ -47,7 +47,8 @@ ELFILES =					\
   emacs/guix-ui.el				\
   emacs/guix-ui-package.el			\
   emacs/guix-ui-generation.el			\
-  emacs/guix-utils.el
+  emacs/guix-utils.el				\
+  emacs/site-start.el
 
 if HAVE_EMACS
 
diff --git a/emacs/site-start.el b/emacs/site-start.el
new file mode 100644
index 0000000..5242082
--- /dev/null
+++ b/emacs/site-start.el
@@ -0,0 +1,4 @@
+;; Autoload Emacs packages installed in ~/.guix-profile.
+(when (require 'guix-emacs nil t)
+  (add-to-list 'load-path (guix-emacs-directory))
+  (guix-emacs-load-autoloads))
-- 
2.6.3

Re: Emacs load path

[Federico Beffa]

On Tue, Jan 5, 2016 at 10:40 AM, Alex Kost <alezost@gmail.com> wrote:
> Federico Beffa (2016-01-04 13:18 +0300) wrote:
>
>> On Sat, Jan 2, 2016 at 3:13 PM, Alex Kost <alezost@gmail.com> wrote:
>>> Federico Beffa (2016-01-01 19:53 +0300) wrote:
> [...]
>>>> there's no 'guix-config.el', but only 'guix-config.el.in'. It would be
>>>> great if you could provide a working patch.
>>>
>>> Hm, OK, so your "proof of concept patch" will have the same problem.
>>> Could you please answer
>>> <http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00021.html>, as
>>> I still don't understand how your suggestion can help Emacs to find
>>> packages in "guix.d" dirs of user profile.
>>
>> That's the easy part. Once we know how to load a minimal version of
>> your code, we add it to 'site-start.el'. Emacs automatically loads it.
>
> Ah, now I see what you mean, thanks!  And emacs can be started with
> "--no-site-file" so my concerns about avoiding this are fulfilled.  For
> simplicity, we can even add "site-start.el" to the guix repo I think.

Fine with me. I don't have preferences on this.

>>> Returning to 'guix-config' problem, we can make a "soft" dependency on
>>> 'guix-profiles' (see the attached patch), so the only file needed for
>>> finding emacs packages in "guix.d" will be "guix-emacs.el".  And the
>>> code that should be loaded by Emacs to find guix emacs packages will be:
>>>
>>> (when (require 'guix-emacs nil t)
>>>   (add-to-list 'load-path (guix-emacs-directory))
>>>   (guix-emacs-load-autoloads))
>>
>> I've done this, but it doesn't load as 'guix-config' is missing. I
>> guess it needs your patch which I didn't try.
>
> Yes, it meant to be used with the patch.
>
> So IIUC we need the following patches to make our Emacs find packages in
> a user profile:
>
> - patch for stripping "guix-emacs.el" from extra dependencies (attached
>   to the previous message);
>
> - patch for adding "site-start.el" (attached to this message);
>
> - modified version of your patch to copy "site-start.el" and
>   "guix-emacs.el" to the proper places.
>

If you want, feel free to modify and push my patch as needed. At the
moment your patches do not apply on my checkout (I'm behind master by
a few weeks). Otherwise, I will update and try to close this during
one of the next week-ends.

Thanks for the cooperation,
Fede

Re: Emacs load path

[Alex Kost]

Federico Beffa (2016-01-05 16:21 +0300) wrote:

> On Tue, Jan 5, 2016 at 10:40 AM, Alex Kost <alezost@gmail.com> wrote:
>>>> Returning to 'guix-config' problem, we can make a "soft" dependency on
>>>> 'guix-profiles' (see the attached patch), so the only file needed for
>>>> finding emacs packages in "guix.d" will be "guix-emacs.el".  And the
>>>> code that should be loaded by Emacs to find guix emacs packages will be:
>>>>
>>>> (when (require 'guix-emacs nil t)
>>>>   (add-to-list 'load-path (guix-emacs-directory))
>>>>   (guix-emacs-load-autoloads))
>>>
>>> I've done this, but it doesn't load as 'guix-config' is missing. I
>>> guess it needs your patch which I didn't try.
>>
>> Yes, it meant to be used with the patch.
>>
>> So IIUC we need the following patches to make our Emacs find packages in
>> a user profile:
>>
>> - patch for stripping "guix-emacs.el" from extra dependencies (attached
>>   to the previous message);
>>
>> - patch for adding "site-start.el" (attached to this message);

Or even better, move the code for auto-loading emacs packages from
"guix-init.el" to "guix-emacs.el", so "site-start.el" will consist of a
single line: (require 'guix-emacs).

>> - modified version of your patch to copy "site-start.el" and
>>   "guix-emacs.el" to the proper places.
>>
>
> If you want, feel free to modify and push my patch as needed.

Great, thanks!  I have sent a final patchset (including a modified
version of your patch) to improve our Emacs so it should find guix
packages out of the box.

-- 
Alex