unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Cayetano Santos <csantosb@inventati.org>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: emacs packages and elpa
Date: Sun, 31 Dec 2023 17:51:07 +0100	[thread overview]
Message-ID: <87o7e6fgyu.fsf@inventati.org> (raw)
In-Reply-To: <87mstqy3q9.fsf@nicolasgoaziou.fr>



>dim. 31 déc. 2023 at 13:07, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Hello,
>
> Cayetano Santos <csantosb@inventati.org> 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.


      reply	other threads:[~2023-12-31 16:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 10:56 emacs packages and elpa Cayetano Santos
2023-12-31 12:07 ` Nicolas Goaziou via Development of GNU Guix and the GNU System distribution.
2023-12-31 16:51   ` Cayetano Santos [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7e6fgyu.fsf@inventati.org \
    --to=csantosb@inventati.org \
    --cc=guix-devel@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).