Emacs packaging: do we need to pull existing dependencies ?

Emacs packaging: do we need to pull existing dependencies ?

[Cayetano Santos]

Hello Guix,

  I’m referring here to the way we handle propagated-inputs in 
  package
  definitions, when dependencies are already present in the latest
  stable emacs we provide (28.2 as for today.)

  Think for example on all org-packages which depend on (and whose
  package definition declare as a propagated-input) 
  emacs-org. This is
  just an example, as many other similar examples may be found 
  (and
  more to come on the upcoming 29.1).

  From one side, it is up to the upstream package to declare in 
  the
  package-requires fields all of its dependencies. Should not be 
  our
  concern, as packagers, to take care of fixing / replacing that 
  in any
  way. But, from another perspective, most of these packages 
  include
  package-requires coherent to previous versions of emacs, which 
  is not
  the case of guix.

  So, do we need to pull most up to date dependencies, even if 
  already
  present in current emacs, when upstream package requires them to 
  keep
  backward compatibility ? Do we assume that guix emacs (28.2) 
  already
  includes them, and remove the dependency from the inputs ? Is it 
  a
  good strategy to deal with two different versions of a 
  dependency ?

  Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, 
  which
  is not specified in the package definition, meaning we always 
  pull the
  latest available. Do we have to, provided that emacs releases 
  with org
  ? Maybe there is already a clear rule about this topic, but to 
  me this
  is not clear. We have package definitions with both criteria.

  My two cents: let’s keep things as simple as possible. The lower 
  the
  dependencies, the simpler the maintenance. I don’t see the point 
  on
  pulling emacs-org@latest, provided that emacs already includes 
  the
  minimum required org version. Same logic applies to all the 
  rest.

 What do you think ?

Cayetano

emacs packaging: do we need to pull existing dependencies ?

[Cayetano Santos]

Hello Guix,

  I’m referring here to the way we handle propagated-inputs in 
  package
  definitions, when dependencies are already present in the latest
  stable emacs we provide (28.2 as for today.)

  Think for example on all org-packages which depend on (and whose
  package definition declare as a propagated-input) emacs-org. 
  This is
  just an example, as many other similar examples may be found 
  (and
  more to come on the upcoming 29.1).

  From one side, it is up to the upstream package to declare in 
  the
  package-requires fields all of its dependencies. Should not be 
  our
  concern, as packagers, to take care of fixing / replacing that 
  in any
  way. But, from another perspective, most of these packages 
  include
  package-requires coherent to previous versions of emacs, which 
  is not
  the case of guix.

  So, do we need to pull most up-to-date dependencies, even if 
  already
  present in current emacs, when upstream package requires them to 
  keep
  backward compatibility ? Do we assume that guix emacs (28.2) 
  already
  includes them, and remove the dependency from the inputs ? Is it 
  a
  good strategy to deal with two different versions of a 
  dependency ?

  Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, 
  which
  is not specified in the package definition, meaning we always 
  pull the
  latest available. Do we have to, provided that emacs releases 
  with org
  ? Maybe there is already a clear rule about this topic, but to 
  me this
  is not clear. We have package definitions with both criteria.

  My two cents: let’s keep things as simple as possible. The lower 
  the
  dependencies, the simpler the maintenance. I don’t see the point 
  on
  pulling emacs-org@latest, provided that emacs already includes 
  the
  minimum required org version. Same logic applies to all the 
  rest.

What do you think ?

Cayetano

Re: emacs packaging: do we need to pull existing dependencies ?

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 01.02.2023 um 08:44 +0100 schrieb Cayetano Santos:
> [D]o we need to pull most up-to-date dependencies, even if already  
> present in current emacs, when upstream package requires them to 
> keep backward compatibility ? Do we assume that guix emacs (28.2) 
> already includes them, and remove the dependency from the inputs ? Is
> it a good strategy to deal with two different versions of a 
> dependency?
The proper Guix way would actually be to unvendor those packages from
Emacs and offer them separately.  We could certainly do this for quite
a number (e.g. org, cc-mode, ...), but it would be work that someone
has to do and that person better not be lazy like me and take several
months to add native-compilation ;)

> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, 
> which is not specified in the package definition, meaning we always 
> pull the latest available. Do we have to, provided that emacs
> releases with org? Maybe there is already a clear rule about this
> topic, but to me this is not clear. We have package definitions with
> both criteria.
I think it's important to think about this in terms of forward
compatibility.  Is org-roam guaranteed to always work with "the current
version of Emacs, whatever that may happen to be"?  In that case, you
could currently drop emacs-org.  If it requires bleeding edge symbols
on the other hand, or may freely decide that it will need them, adding
emacs-org to the inputs is a good idea.


Cheers

Re: emacs packaging: do we need to pull existing dependencies ?

[Cayetano Santos]

>> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4,
>> which is not specified in the package definition, meaning we always
>> pull the latest available. Do we have to, provided that emacs
>> releases with org? Maybe there is already a clear rule about this
>> topic, but to me this is not clear. We have package definitions with
>> both criteria.

> I think it's important to think about this in terms of forward
> compatibility.  Is org-roam guaranteed to always work with "the current
> version of Emacs, whatever that may happen to be"?  In that case, you
> could currently drop emacs-org.  If it requires bleeding edge symbols
> on the other hand, or may freely decide that it will need them, adding
> emacs-org to the inputs is a good idea.

I don’t see your point. This is exactly the responsibility of the
package, declare its dependencies today, regardless of what the
dependencies will be in the future. This is what the ’package-requires’
field is for, including the version number of the dependencies.

If the dependencies of a given package are already there in emacs (say
org-9.2), why do we need to pull org-latest ? If in the future this
changes, an author decides he needs bleeding edge org features, and
changes the version number of org in the ’package-requires’ field, the
new package definition will propagage-require org-latest. All in all, we
may not predict future package needs, pulling dependencies just in case.

In any case, and whatever the decission, I think we should clearly state
the way to proceed somewhere, as currently we have a mix of both.

C.

Re: emacs packaging: do we need to pull existing dependencies ?

[Liliana Marie Prikler]

Am Sonntag, dem 05.02.2023 um 11:50 +0100 schrieb Cayetano Santos:
> 
> 
> > > Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4,
> > > which is not specified in the package definition, meaning we
> > > always pull the latest available. Do we have to, provided that
> > > emacs releases with org? Maybe there is already a clear rule
> > > about this topic, but to me this is not clear. We have package
> > > definitions with both criteria.
> 
> > I think it's important to think about this in terms of forward
> > compatibility.  Is org-roam guaranteed to always work with "the
> > current version of Emacs, whatever that may happen to be"?  In that
> > case, you could currently drop emacs-org.  If it requires bleeding
> > edge symbols on the other hand, or may freely decide that it will
> > need them, adding emacs-org to the inputs is a good idea.
> 
> I don’t see your point. This is exactly the responsibility of the
> package, declare its dependencies today, regardless of what the
> dependencies will be in the future. This is what the ’package-
> requires’ field is for, including the version number of the
> dependencies.
Still, there's typically a tendency of things going one way or the
other.

> If the dependencies of a given package are already there in emacs
> (say org-9.2), why do we need to pull org-latest ? If in the future
> this changes, an author decides he needs bleeding edge org features,
> and changes the version number of org in the ’package-requires’
> field, the new package definition will propagage-require org-latest.
> All in all, we may not predict future package needs, pulling
> dependencies just in case.
> 
> In any case, and whatever the decission, I think we should clearly
> state the way to proceed somewhere, as currently we have a mix of
> both.
Because people tend to be lazy.  If org-whatever used to require
bleeding edge org sometime in the past, we won't change it back to the
one shipped with emacs because 29.1 is out.  If it only ever used the
emacs stuff and is backwards-compatible with 25, we might not notice
that it even declares the dependency.

I gave you both a purist and a pragmatic solution, so you can choose
which to follow.  I won't press you one way or the other.

Cheers

Re: emacs packaging: do we need to pull existing dependencies ?

[Simon Tournier]

Hi,

On mer., 01 févr. 2023 at 08:44, Cayetano Santos <cayetano.santos@l2it.in2p3.fr> wrote:

> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4,
> which is not specified in the package definition, meaning we always
> pull the latest available. Do we have to, provided that emacs
> releases with org ? Maybe there is already a clear rule about this
> topic, but to me this is not clear. We have package definitions with
> both criteria.

Well, I think it is a collateral effect from the importer.

--8<---------------cut here---------------start------------->8---
$ guix import elpa -a melpa org-roam
[...]

  (propagated-inputs (list emacs-dash emacs-org emacs-emacsql
                           emacs-emacsql-sqlite emacs-magit-section))
--8<---------------cut here---------------end--------------->8---

when MELPA indeed reads:

--8<---------------cut here---------------start------------->8---
Dependencies
    dash 2.13 / emacs 26.1 / emacsql 3.0.0 / emacsql-sqlite 1.0.0 / magit-section 3.0.0 / org 9.4
--8<---------------cut here---------------end--------------->8---

Indeed, emacs-org-roam@2.2.2 should work with emacs@28.2 (provided by
default with the current Guix) and thus the propagated-inputs emacs-org
is totally not required.

Well, a curation would some work; first to find all the removable items,
then second to maintain after each package “refresh”.  Such curation
would fit in all the discussions around the closure diet of Guix
packages.

However, it appears to me that people currently maintaining all the
Emacs packages in Guix should decide; since it would be extra work for
them. :-)

Cheers,
simon

Emacs packaging: do we need to pull existing dependencies ?

[Cayetano Santos]

Hello Guix,

  I’m referring here to the way we handle propagated-inputs in 
  package
  definitions, when dependencies are already present in the latest
  stable emacs we provide (28.2 as for today).

  Think for example on all org-packages which depend on (and whose
  package definition declare as a propagated-input) emacs-org. 
  This is
  just an example, as many other similar examples may be found 
  (and more
  to come on the upcoming 29.1).

  From one side, it is up to the upstream package to declare in 
  the
  package-requires fields all of its dependencies. Should not be 
  our
  concern, as packagers, to take care of fixing / replacing that 
  in any
  way.

  But, from another perspective, most of these packages include
  package-requires coherent to previous versions of emacs, which 
  is not
  the case of guix.

  So, do we need to pull most up to date dependencies, even if 
  already
  present in current emacs, when upstream package requires them to 
  keep
  backward compatibility ? Do we assume that guix emacs (28.2) 
  already
  includes them, and remove the dependency from the inputs ? Is it 
  a
  good strategy to install two different versions of a dependency 
  ?

  Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, 
  which
  is not specified in the package definition, meaning we always 
  pull the
  latest available. Do we have to, provided that emacs releases 
  with org
  ?

  Maybe there is already a clear rule about this topic, but to me 
  this
  is not clear. We have package definitions with both criteria.

  My two cents: let’s keep things as simple as possible. The lower 
  the
  dependencies, the simpler the maintenance. I don’t see the point 
  on
  pulling emacs-org@latest, provided that emacs already includes 
  the
  minimun required org version. Same logic applies to all the 
  rest.

  What do you think ?

Cayetano