Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Philip Kaludercic [2022-10-19 07:08:34] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I have pushed a first draft and it appears to work.  It doesn't yet
>>>> handle all attribute (such as :doc), but that should be doable when I
>>>> find the time.
>>> Side note: installing packages from Git (like what you're implementing
>>> in the `package+vc` branch) is already one of the functionalities
>>> supported by `elpa-admin.el` so it would be good to try and share/reuse
>>> that code as much as possible.
>> That is only possible insofar I don't have to rely on Git features,
>> since package-vc intends to be VC-generic.
>
> I'm thinking of things like the code that handles `:doc` or `:make`.
> These don't care about Git.

For something like :make to work, we would also require :renames, right?
But if that is added, then the version control could break.

> I don't think that the code in `elpa-admin.el` can be used as-is, but it
> would be good to try and change them in tandem (maybe by extracting the
> common code into some new file?).
>
>>> Actually part of `elpa-admin.el` might also be helpful for the
>>> ELPA-bundling feature.
>>> So we should move more of `elpa-admin.el` into Emacs's own code.
>> As part of `package-vc' or as a new module?
>
> I think either way is fine.  The whole `elpa-admin.el` contains things
> that are irrelevant to Emacs itself, so we'll likely keep a separate
> file like that, but the code that's useful for other uses
> (i.e. package-vc and/or bundled-ELPA) should be moved out (tho
> elpa-admin.el has to be backward compatible to some extent, so we'll
> have to keep a "local" copy of whatever is moved to a common file
> hosted in emacs.git, at least for a few years).

How does this look like:

0001-elpa-admin.el-elpaa-batch-make-all-packages-Generate.patch
Description: Text Data

It currently makes the assumption that :core is the first element in the
property list for each package specification.  This appears to be the
convention and makes the code simpler, but if you think it is not
justified, that part can be reworked.