[ELPA] Maintaining multiple packages in the same repo, branch, and worktree

[ELPA] Maintaining multiple packages in the same repo, branch, and worktree

[Adam Porter]

Hi Stefan, et al,

After having split taxy-magit-section.el into a separate branch of the
taxy.el git repo, Jonas recently pointed out that this doesn't work well
with some other tools:

https://github.com/alphapapa/taxy.el/issues/3

And as I mention there, it can be easier for the package developer to
keep two closely related packages' source files in the same repo,
branch, and worktree.  That's certainly the case for me with taxy and
taxy-magit-section: while they should be packaged separately, and while
development of them has settled down a bit, they are closely related,
still young, and changes in one may require changes in the other.  So it
would be preferable for me to keep the files side-by-side.

Despite the unwieldy list of :ignored-files in the elpa-packages file,
this is how Magit and Magit Section are packaged in NonGNU ELPA: they
come from the same repo, branch, and worktree, and their "recipes" are
configured appropriately.

So, if it's acceptable, I'd like to revert to keeping taxy and
taxy-magit-section in the same repo and branch, and to update the recipe
in elpa-packages with the appropriate :ignored-files lists.

While I don't want to make extra work for Stefan or anyone else
maintaining ELPA, it seems like optimizing for the package developer's
ease should be prioritized over making the automated build process
easier.  If improvements need to be made to that process, maybe we could
discuss making them.

-- 
Thanks,
Adam

Re: [ELPA] Maintaining multiple packages in the same repo, branch, and worktree

[Stefan Monnier]

> Despite the unwieldy list of :ignored-files in the elpa-packages file,
> this is how Magit and Magit Section are packaged in NonGNU ELPA: they
> come from the same repo, branch, and worktree, and their "recipes" are
> configured appropriately.

Indeed, that's how Magit does it currently, which sucks for users who
install those packages directly from the Git rather than via
the tarballs.
[ It also makes for spurious extra messages in the cron logs and
  elpa-diffs.  ]

I accepted it because it was complicated for Magit to change that.

I think it could be made acceptable more generally (which would also be
appreciated for ivy/avy/swiper) by improving `elpa-admin.el` the way
Jonas suggests: allow a package to specify explicitly that it (re)uses
the same files as some other package.  Then `elpa-admin.el` could setup
`.../elpa/packages/<pkg>` as a symlink to the other package and it could
skip the package when performing operations that
are redundant (e.g. sync'ing).

We'd still get some downsides (e.g. all the packages sharing the same
source code would still end up being duplicated in the `load-path` when
installed from Git), but I think it would be tolerable.

> If improvements need to be made to that process, maybe we could
> discuss making them.

Yes, I think the changes to `elpa-admin.el` wouldn't be too complex.


        Stefan