Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.

[Basil L. Contovounesios]

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