Re: package-vc support for :files keyword

[Philip Kaludercic]

Tony Zorman <tonyzorman@mailbox.org> writes:

> On Mon, Sep 18 2023 09:10, Philip Kaludercic wrote:
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>> here's an idea: why not create e.g. a variable to decide when
>>> :shell-command is executed? Moving the execution to right after cloning
>>> the repository, instead of before building documentation, would enable
>>> one to easily emulate :files directives, as well as other keywords that
>>> need to be executed before things actually get built.
>>>
>>> Alternatively one could have a second :shell-command like keyword.
>>
>> My issue with the first idea would be that this would create a greater
>> discrepancy between what elpa-admin and package-vc do.  So if anything,
>> I think only the second option, e.g. :early-shell-command, would be
>> viable.
>
> Fair enough.
>
>> In both cases, what would you imagine that the command would do?  If it
>> just calls "rm foo.el bar.el ...", then we have an issue when upgrading,
>> because there would at least be a merge conflict any time the other
>> files are modified upstream.  Upgrading isn't easy the way it is, but
>> raising the necessity for manual intervention every time is something
>> I'd like to avoid.
>
> I think that
>
>   $ rm foo.el
>   $ git update-index --assume-unchanged foo.el
>
> should work. It should merge cleanly (I've tried this out just now, and
> it worked, but I may have overlooked something). If it's part of the
> package description, then updating should work out of the box, since
> package-vc-upgrade also calls package-vc--unpack-1, which would execute
> the respective :early-shell-command again.

Being a git-specific command, this shouldn't be added to package-vc
directly.  If there is a VCS agnostic/generalisable way of doing this,
then it could be added to VC.

But for now, if I understand you correctly, you are suggesting that
users give package specifications like this:

(foo :url "https://some.vcs/repository";
     ;; ...
     :early-shell-command "rm [all the files]; git update-index 
--assume-unchanged [all the files]")

where [all the files] might change between updates.

At this point I continue to question the utility of emulating
MELPA-style :files attributes, unless there are concrete usability
issues.

For the record, these are all the repositories in {Non,}GNU ELPA that
develop multiple packages in a single repository:

GNU ELPA:
http://www.dr-qubit.org/git/predictive.git
https://github.com/oantolin/embark
https://github.com/abo-abo/swiper
https://github.com/abo-abo/hydra
https://github.com/alphapapa/taxy.el.git

NonGNU ELPA:
https://github.com/lewang/flx
https://github.com/emacs-helm/helm
https://github.com/magit/magit
https://github.com/brianc/jade-mode

>From what I understand, there is no technical necessity for this mode of
development?  I wonder how difficult it would be to push for a
one-package-one-repo approach.

>> Also, what would a :early-shell-command be used for
>> on the ELPA build server?
>
> That I don't know, I've never consciously looked at the ELPA build
> server.

-- 
Philip Kaludercic