[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package-vc support for :files keyword

From: Philip Kaludercic
Subject: Re: package-vc support for :files keyword
Date: Mon, 18 Sep 2023 15:52:37 +0000

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

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



>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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]