[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: |
Tue, 19 Sep 2023 13:56:23 +0000 |
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> On 9/19/23 03:37, Philip Kaludercic wrote:
>
>>> Please note out that while `taxy' and `taxy-magit-section' are both
>>> developed in "taxy.el.git", they are in separate branches, so there is
>>> no need to build the two packages from a single set of files by
>>> excluding some files and then the others.
>> Oops, I just wrote a quick script that compared URLs but did not
>> check
>> what :branch they are developed on.
>>
>>> I've chosen to keep these packages in the same repo because they are
>>> so closely related. I'd like to be able to keep this arrangement.
>> That is totally fine, would you mind sharing your setup, in case
>> someone
>> else is interested in this approach as well?
>
> I'm not sure what you're asking for, but I'll be glad to share. All I
> did was create an orphan branch in the same repository and add the
> "taxy-magit-section.el" and associated files there, as if it were a
> separate repo.
What I meant was if you just had multiple, separate checkouts of the
same repository or were using something more fancy like git worktrees.
>>> Having said that, while I wouldn't personally object to dropping
>>> support for building multiple packages from a single branch (since I
>>> don't do it myself), I wouldn't favor doing so, because existing
>>> packages do, and it would create more work for the authors to have to
>>> split them up.
>> That is the issue, and I certainly don't want to be the one to blame
>> for
>> breakage, be it for package developers let alone users.
>>
>>> Maybe it would be reasonable to make a new policy against building
>>> multiple packages from a single branch, while "grandfathering" in the
>>> existing packages that do so, if it would solve a problem for ELPA.
>> What do you mean by "grandfathering"?
>
> It's an expression; in this context, it would mean to allow the
> packages that already work this way to continue doing so, while
> requiring newly submitted packages to only build one package per
> branch (or repo, depending on the policy).
FWIW I have been bringing this up whenever a package like this was
proposed, but usually they refer to existing users on MELPA and then I
don't want to bother them any further.
- Re: package-vc support for :files keyword, Tony Zorman, 2023/09/18
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/18
- Re: package-vc support for :files keyword, Tony Zorman, 2023/09/18
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/18
- Re: package-vc support for :files keyword, Adam Porter, 2023/09/18
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/19
- Re: package-vc support for :files keyword, Adam Porter, 2023/09/19
- Re: package-vc support for :files keyword,
Philip Kaludercic <=
- Re: package-vc support for :files keyword, Adam Porter, 2023/09/19
- Re: package-vc support for :files keyword, Tony Zorman, 2023/09/18
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/19
- Re: package-vc support for :files keyword, Adam Porter, 2023/09/19
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/19
- Re: package-vc support for :files keyword, Tony Zorman, 2023/09/19
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/20
- Re: package-vc support for :files keyword, Tony Zorman, 2023/09/21
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/21
- Message not available
- Re: package-vc support for :files keyword, Philip Kaludercic, 2023/09/24