Re: emacs packages and elpa

[Cayetano Santos]

>dim. 31 déc. 2023 at 13:07, Nicolas Goaziou  wrote:

> Hello,
>
> Cayetano Santos  writes:
>
>>   We distribute emacs packages from gnu/elpa by downloading .tar files
>>   from there: I’m thinking about emacs-ggtags.
>>
>>   My first concern is, what emacs-ggtags 0.9.0 corresponds to exactly ?
>>   There is no 0.9.0 tag in upstream github reposotory, and, if I
>>   understand it correctly, elpa just mirrors it
>>
>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/ggtags
>>
>>   So what exactly 0.9.0 is ? They bump on the 2018-07-26.  Does it refer
>>   to something more recent ? How to know ? This is for sure elpa
>>   related, ... but we are distributing packages based on their criteria.
>>   It would be great to understand how it goes (at this point, I cannot
>>   clone elpa, for some reason).
>
> For Emacs packages, "Version" keyword in main file, here "ggtags.el", is
> more important than tags because each time that keyword is updated,
> a new release happens on ELPA. In a nutshell, "0.9.0" refers to the
> commit that updated the keyword.

Good to know, thanks.

>>   My second concern is, how do we distribute some more up to date (think
>>   emacs-magit), if we use a .tar from elpa ? When developer decides not
>>   to / forgets to tag a new release, how do we proceed ? Do we use
>>   elpa.gnu.org/devel instead ? I cannot see any example of guix
>>   sources.
>
> As pointed out, upstream tags do not matter for ELPA release cycles.

I see.

Its a bit surprising, because the biggest advantage of guix is being
reproducible and deterministic: one always knows without any ambiguity
which code is in use, by just having a look at guix itself. Having an
extra layer between upstream and the package is kind of weird to me.

> If you need to package a more up-to-date package (with good reasons,
> I hope), you just point source to upstream instead of ELPA.

Regarding ggtags, it is from 5 years ago. More recent updates include
xref support, among others. I think its worth updating.

C.

emacs packages and elpa

[Cayetano Santos]

Hello Guix,

  We distribute emacs packages from gnu/elpa by downloading .tar files
  from there: I’m thinking about emacs-ggtags.

  My first concern is, what emacs-ggtags 0.9.0 corresponds to exactly ?
  There is no 0.9.0 tag in upstream github reposotory, and, if I
  understand it correctly, elpa just mirrors it

https://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/ggtags

  So what exactly 0.9.0 is ? They bump on the 2018-07-26.  Does it refer
  to something more recent ? How to know ? This is for sure elpa
  related, ... but we are distributing packages based on their criteria.
  It would be great to understand how it goes (at this point, I cannot
  clone elpa, for some reason).

  My second concern is, how do we distribute some more up to date (think
  emacs-magit), if we use a .tar from elpa ? When developer decides not
  to / forgets to tag a new release, how do we proceed ? Do we use
  elpa.gnu.org/devel instead ? I cannot see any example of guix sources.

Best,

C.

[emacs]: snapshots against latest versions

[Cayetano Santos]

Hi Guix,

  Following a recent patch to an snapshot of an emacs package
  (emacs-mastodon), where latest stable (tagged) release dates back from
  a long time, the question of whether to send patches for non stable
  (tagged) versions is pertinent or not.

  Of course, the answer is clear: we only package stable. Guix manual
  (22.4.3 Version Numbers) clearly states that "We usually package only
  the latest version of a given free software project ... Occasionally,
  we package snapshots of upstream’s version control system (VCS)
  instead of formal releases.  This should remain exceptional.". Fine
  with that.

  Now, regarding emacs-xyz packages, the situation is a bit ambiguous.
  We have (old?) (tagged) releases, as well as snapshots. What is the
  rule to follow when we contribute ? At what point in time do we
  consider we may submit patches for snapshots ? With which frequency ?
  Do we consider number or relevance of commits since latest version ?
  Do we base our decision on time elapsed ? Simply put, as for now, we
  have a mix of melpa-stable and melpa: when one may decide to forget
  stable and move forward to latest ? Of course, this is author’s role,
  but I’m wondering how subjective all of this is, and how this might
  impact quality of provided packages.

Best,

Cayetano

Re: Emacs next variants

[Cayetano Santos]

>ven. 10 mars 2023 at 22:44, Andrew Tropin  wrote:

> [[PGP Signed Part:Undecided]]
> On 2023-03-10 19:24, Cayetano Santos wrote:
>
>>>ven. 10 mars 2023 at 19:14, Simon Tournier  wrote:
>>
>>> Hi,
>>>
>>> On Fri, 10 Mar 2023 at 17:59, John Kehayias
>>>  wrote:
>>>
>>>> During this discussion some changes were made to this inheritance 
>>>> structure in
>>>>
>>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4c64ddce44bb31332784c3f8e037bd565194604>
>>>>
>>>> and
>>>>
>>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=070c335a91d5c245f0360e12c794e9109f9faaf1>
>>>
>>> Thanks for pointing that.  From my understanding, it does not change
>>> what Cayetanos is raising: emacs-next-tree-sitter is built using
>>> '--with-pgtk'.  In fact, the package emacs-next-tree-sitter is built
>>> using the master branch (Emacs 30 unbranched yet) with tree-sitter
>>> *and* pgtk support.
>>>
>>> Cheers,
>>> simon
>>
>> As for the NEWS-29 file:
>>
>> "Running this configuration on X is known to have problems, such as
>> undesirable frame positioning and various issues with keyboard input of
>> sequences such as 'C-;' and 'C-S-u'."
>>
>> C.
>
> I haven't used X for a while, but if it's still the case for 30 version,
> I guess we can inherit pgtk from tree-sitter.
>
> This will update emacs-next-pgtk from emacs-29 to somewhere near 30 on
> master, but I it should be fine. I use the same commit as
> emacs-next-tree-sitter in my local tree-sitter+pgtk emacs package and
> everything seems to work for me.
>
> WDYT?

Personally, the closer to master, the better (and the simpler). What you
propose, inheritance of pgtk from tree-sitter, fits me well.

C.

Re: Emacs next variants

[Cayetano Santos]

>ven. 10 mars 2023 at 19:14, Simon Tournier  wrote:

> Hi,
>
> On Fri, 10 Mar 2023 at 17:59, John Kehayias
>  wrote:
>
>> During this discussion some changes were made to this inheritance structure 
>> in
>>
>> 
>>
>> and
>>
>> 
>
> Thanks for pointing that.  From my understanding, it does not change
> what Cayetanos is raising: emacs-next-tree-sitter is built using
> '--with-pgtk'.  In fact, the package emacs-next-tree-sitter is built
> using the master branch (Emacs 30 unbranched yet) with tree-sitter
> *and* pgtk support.
>
> Cheers,
> simon

As for the NEWS-29 file:

"Running this configuration on X is known to have problems, such as
undesirable frame positioning and various issues with keyboard input of
sequences such as 'C-;' and 'C-S-u'."

C.

Re: Emacs next variants

[Cayetano Santos]

>ven. 10 mars 2023 at 13:07, Simon Tournier  wrote:

> Note that emacs-next-tree-sitter is not from the 29 branch (emacs-next)
> but from the 30 branch.  Therefore, it would mean emacs-next-pgtk also
> be an Emacs 30 version.  I do not use them so I have not opinion.
>
> And why not split the chain, i.e., having:
>
> (define-public emacs-next-pgtk
>   (package
> (inherit emacs-next)
>
> and
>
> (define-public emacs-next-tree-sitter
> (package
>   (inherit emacs-next)
>
> ?

Fine with me, even if to me emacs-next means latest from master,
including tree-sitter. You decide to use the feature, or not.

Gtk is something else, as it imposes a strong limitation on the use of
emacs (wayland).

C.

Emacs next variants

[Cayetano Santos]

Hi guix,

  As for today, the inheritance of emacs, master branch, variants is as
  follows

(emacs-next-tree-sitter (emacs-next-gtk (emacs-next (emacs

  Having tree-sitter is really useful, but optional, and doesn’t produce
  any harm to users. They may opt to use it, or not.

  This is not the case of the gtk variant. If one wants to use
  tree-sitter, the gtk variant is mandatory. When under x server, this
  produces a welcome warning advising about unattended effects, crashes,
  and leak of support when combining gtk emacs with x server.

  So, is there any reason for this dependency chain ? Why not ?

(emacs-next-gtk (emacs-next-tree-sitter (emacs-next (emacs

Best,

Cayetano

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.

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 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

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