From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, Oleh Krehel <oleh@oremacs.com>
Subject: Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.
Date: Thu, 11 Mar 2021 17:12:18 +0000 [thread overview]
Message-ID: <87im5x8vil.fsf@tcd.ie> (raw)
In-Reply-To: <jwvwnudn1l0.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 11 Mar 2021 10:48:26 -0500")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> - as discussed earlier, we could have each subpackage have the complete
>>> upstream Git and only create the subpackages via `elpa-package`
>>> filtering out the other files.
>> That would be nice to have in general, but it doesn't solve the
>> inefficiency when multiple packages are bundled from the same repo.
> I don't understand the "when ..." qualification, since my suggestion is
> only meaningful in that precise case. As for the inefficiency: as long
> as the upstream is not enormous and that we don't have too many packages
> following that model, it's bearable.
If that's acceptable (albeit discouraged), then that could work, yes.
>>> - if there's really only one version number shared by all the
>>> sub-packages, I'd tend to argue that maybe there should only be one
>>> package ;-)
>> I tend to agree ;). Not my call to make, though, and that ship is
>> either getting smaller or sailing away.
>>> - split the upstream repository.
>> Not my call to make.
>
> Of course it can also be a mix of the two and it can be done in bits and
> pieces: every bit helps. So maybe we can start by lobbying the upstream
> for one specific subpackage we identified as being a good candidate for
> either a separate upstream repository or for having the subpackage be
> merged with another.
Consider this the lobby, then :). (Oleh is already CCed.)
Just today I had to bump only ivy-hydra's version, because it was
unnecessarily requiring a newer version of hydra that hasn't yet been
pushed to elpa.git.
The packages ivy-avy and ivy-hydra are considered optional integrations
with the separate packages avy and hydra, respectively, so they seem
like the best candidates for splitting into separate packages (or
merging with the avy and hydra packages, I think).
ivy, swiper, and counsel are too coupled to split, I think. So my vote
is for either distributing ivy, swiper, counsel, ivy-avy, and ivy-hydra
as a single superpackage that mirrors swiper.git development, or
splitting ivy-avy and ivy-hydra out of swiper.git.
>> I guess another alternative to :version-map would be Git tags?
>> E.g. using an N.N.N-elpa scheme or something like that.
>
> Fetching tags from upstream is problematic (because we have a single
> elpa.git repository for all packages), but we could use tags manually
> pushed to elpa.git, yes.
I was thinking of the latter indeed, as a more "Git-native" way of
pointing to a release.
I can't promise to implement any of these features for another few
months though (at least not without a guilty conscience ;).
Thanks,
--
Basil
next prev parent reply other threads:[~2021-03-11 17:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210225102521.11653.64611@vcs0.savannah.gnu.org>
[not found] ` <20210225102523.7CEF420B28@vcs0.savannah.gnu.org>
2021-02-25 14:33 ` [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync Basil L. Contovounesios
2021-02-25 15:12 ` Stefan Monnier
2021-02-25 16:24 ` Basil L. Contovounesios
2021-02-25 16:40 ` Stefan Monnier
2021-03-09 22:17 ` Basil L. Contovounesios
2021-03-09 23:56 ` Stefan Monnier
2021-03-10 12:40 ` Basil L. Contovounesios
2021-03-11 15:48 ` Stefan Monnier
2021-03-11 17:12 ` Basil L. Contovounesios [this message]
2021-03-11 17:34 ` Stefan Monnier
2021-03-11 19:25 ` Basil L. Contovounesios
2021-03-11 22:47 ` Stefan Monnier
2021-03-11 22:59 ` Basil L. Contovounesios
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im5x8vil.fsf@tcd.ie \
--to=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=oleh@oremacs.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.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.