* emacs packaging: do we need to pull existing dependencies ?
@ 2023-02-01 7:44 Cayetano Santos
2023-02-04 17:58 ` Liliana Marie Prikler
2023-02-06 16:53 ` Simon Tournier
0 siblings, 2 replies; 7+ messages in thread
From: Cayetano Santos @ 2023-02-01 7:44 UTC (permalink / raw)
To: Guix Devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs packaging: do we need to pull existing dependencies ?
2023-02-01 7:44 emacs packaging: do we need to pull existing dependencies ? Cayetano Santos
@ 2023-02-04 17:58 ` Liliana Marie Prikler
2023-02-05 10:50 ` Cayetano Santos
2023-02-06 16:53 ` Simon Tournier
1 sibling, 1 reply; 7+ messages in thread
From: Liliana Marie Prikler @ 2023-02-04 17:58 UTC (permalink / raw)
To: cayetano.santos, Guix Devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs packaging: do we need to pull existing dependencies ?
2023-02-04 17:58 ` Liliana Marie Prikler
@ 2023-02-05 10:50 ` Cayetano Santos
2023-02-05 19:46 ` Liliana Marie Prikler
0 siblings, 1 reply; 7+ messages in thread
From: Cayetano Santos @ 2023-02-05 10:50 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: guix-devel
>> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs packaging: do we need to pull existing dependencies ?
2023-02-05 10:50 ` Cayetano Santos
@ 2023-02-05 19:46 ` Liliana Marie Prikler
0 siblings, 0 replies; 7+ messages in thread
From: Liliana Marie Prikler @ 2023-02-05 19:46 UTC (permalink / raw)
To: csantosb; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs packaging: do we need to pull existing dependencies ?
2023-02-01 7:44 emacs packaging: do we need to pull existing dependencies ? Cayetano Santos
2023-02-04 17:58 ` Liliana Marie Prikler
@ 2023-02-06 16:53 ` Simon Tournier
1 sibling, 0 replies; 7+ messages in thread
From: Simon Tournier @ 2023-02-06 16:53 UTC (permalink / raw)
To: cayetano.santos, Guix Devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Emacs packaging: do we need to pull existing dependencies ?
@ 2023-01-31 8:13 Cayetano Santos
0 siblings, 0 replies; 7+ messages in thread
From: Cayetano Santos @ 2023-01-31 8:13 UTC (permalink / raw)
To: Guix Devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Emacs packaging: do we need to pull existing dependencies ?
@ 2023-01-29 18:27 Cayetano Santos
0 siblings, 0 replies; 7+ messages in thread
From: Cayetano Santos @ 2023-01-29 18:27 UTC (permalink / raw)
To: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-02-06 18:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-01 7:44 emacs packaging: do we need to pull existing dependencies ? Cayetano Santos
2023-02-04 17:58 ` Liliana Marie Prikler
2023-02-05 10:50 ` Cayetano Santos
2023-02-05 19:46 ` Liliana Marie Prikler
2023-02-06 16:53 ` Simon Tournier
-- strict thread matches above, loose matches on Subject: below --
2023-01-31 8:13 Emacs " Cayetano Santos
2023-01-29 18:27 Cayetano Santos
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.