Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Xinglu Chen]

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

On Wed, Sep 01 2021, Andrew Tropin wrote:

> On 2021-08-30 15:33, Xinglu Chen wrote:
>
>> On Mon, Aug 30 2021, Andrew Tropin wrote:
>>
>>>> Why would it be more consistent to make a separate package?  Making a
>>>> separate package is usually used for packaging a slightly different
>>>> version of the “regular” package, e.g., ‘emacs-next-pgtk’ adds native
>>>> compilation and pure GTK support for Emacs., ‘emacs-no-x’ removes X
>>>> suport for ‘emacs’.  ‘emacs-notmuch’ isn’t really a different version of
>>>> ‘notmuch’, it’s just ‘notmuch’ but with all the non-Elisp stuff
>>>> removed.  This is usually what using different outputs tries to achieve,
>>>> e.g., separate documentation from the main package, or in this case,
>>>> separate Elisp stuff from the main package.
>>>>
>>>
>>> Almost all elisp packages in Guix have a emacs- prefix, so as a user I
>>> expect to find notmuch*.el in emacs-notmuch package and notmuch binary
>>> in notmuch package, despite the fact that upstream distributes the
>>> source code for both of them in one tarball.
>>
>> Good point, however, If we were to have separate ‘emacs-’ packages for
>> the packages that also contain Elisp stuff, should those packages still
>> include the Emacs package in their output, i.e., should the ‘notmuch’
>> package still include notmuch.el, or should the Elisp stuff only be in
>> ‘emacs-notmuch’?
>>
>
> IMO, notmuch package should not include Elisp stuff, at least I don't
> see use cases, where it can be useful, but see where it can be
> harmful.

Should this apply to other packages that contains Elisp stuff too, or is
it specific to ‘notmuch’?

Cc’ing guix-devel to see what other people think before we start
breaking people’s setups.  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Liliana Marie Prikler]

Am Mittwoch, den 01.09.2021, 14:05 +0200 schrieb Xinglu Chen:
> > IMO, notmuch package should not include Elisp stuff, at least I
> > don't see use cases, where it can be useful, but see where it can
> > be harmful.
> 
> Should this apply to other packages that contains Elisp stuff too, or
> is it specific to ‘notmuch’?
> 
> Cc’ing guix-devel to see what other people think before we start
> breaking people’s setups.  :-)
In my personal opinion providing a separate package (perhaps one using
emacs-build-system) is to be preferred as per the principle of least
surprise.  However, in some situations we might want to hold back on
that, e.g. if providing an extra emacs package would entail propagating
the original package just because.

On current master, there's quite a number of packages that require
mixing emacs-build-system into something else.  Reducing this number
would make changes to emacs-build-system cause less breakages, some of
which we've seen in the past and some of which could possibly happen in
the future, if e.g. post native-compilation we realize that we need an
extra phase to deal with <insert stuff here>.

TL;DR: I'm generally in favor of branching emacs support packages off,
even if origins are to be inherited.

Regards

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Carlo Zancanaro]

On Wed, Sep 01 2021, Liliana Marie Prikler wrote:
> TL;DR: I'm generally in favor of branching emacs support 
> packages off, even if origins are to be inherited.

This is my preference, and there is precedent for this in Guix 
already. I know of emacs-protobuf-mode and emacs-erlang which are 
separate packages, but which reference the source of an existing 
package (with (package-source protobuf) and (package-source 
erlang), respectively).

I like how easy it is to discover Emacs packages by looking for 
the emacs- prefix. Mu and notmuch already violate that prefix 
expectation, moving their elisp into a separate output would be 
further hiding the Emacs modes.

Carlo

[bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Xinglu Chen]

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

On Thu, Sep 02 2021, Carlo Zancanaro wrote:

> On Wed, Sep 01 2021, Liliana Marie Prikler wrote:
>> TL;DR: I'm generally in favor of branching emacs support 
>> packages off, even if origins are to be inherited.
>
> This is my preference, and there is precedent for this in Guix 
> already. I know of emacs-protobuf-mode and emacs-erlang which are 
> separate packages, but which reference the source of an existing 
> package (with (package-source protobuf) and (package-source 
> erlang), respectively).
>
> I like how easy it is to discover Emacs packages by looking for 
> the emacs- prefix. Mu and notmuch already violate that prefix 
> expectation, moving their elisp into a separate output would be 
> further hiding the Emacs modes.
>
> Carlo

Looks like there is consensus on the matter, unless someone objects, I
will send an updated series that adds ‘emacs-notmuch’ instead of adding
an extra output to ‘notmuch’.  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[zimoun]

Hi,

On Wed, 01 Sep 2021 at 14:05, Xinglu Chen <public@yoctocell.xyz> wrote:

> Cc’ing guix-devel to see what other people think before we start
> breaking people’s setups.  :-)

I agree with this Andrew’s comment:

        P.S. I know that there are some emacs packages in Guix already, which
        doesn't use emacs-build-system, but I think we should keep that number
        as low as possible and ideally to make it equal to 0 =)
        
<http://issues.guix.gnu.org/issue/50077#5>

If I do:

  guix install emacs-next notmuch

then there is no guarantee that “M-x notmuch” will work.  Because
’notmuch.el’ is byte-compiled using ’emacs-no-x’.  The issue is that
some Emacs packages rely on ’emacs-minimal’, others on ’emacs-no-x’ as
input, others on other Emacs VM variant, therefore the transformation

  guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

will not work, as pointed by Nicolas here [1].  Well, you will tell me
that ’outputs’ does not change much the issue. :-) For sure, but IMHO
having Emacs packages using ’emacs-build-system’ eases the write of
generic transformation.  Well, there is enough corner cases with Emacs
packages using ’emacs-build-system’ which rewriting their ’#:emacs’
argument.  Other speaking about Emacs packages using other build
systems.

Another point is, if I want to build ’notmuch’ but I am not an Emacs
user, then:

  guix environment notmuch

will download ’emacs-no-x’ for nothing.  When my network is poor, I am
unhappy.  Although, it is already the case. :-) Well, this is something
known, see:

<https://git.savannah.gnu.org/cgit/guix.git/tree/TODO#n37>

I am not convinced that several outputs help.  And generally speaking,
personally, I tend to prefer package inherit over several outputs.
Matter of taste I guess. :-)

Without speaking about cross-compilation. ;-)

From my point of view, I would split the package ’notmuch’ and propagate
this new ’notmuch’ package with a new ’emacs-notmuch’ (if ’notmuch.el’
requires it).  Well, from my point of view, it would be how to improve
the situation. :-)


All the best,
simon

1: <http://issues.guix.gnu.org/41732#14>