emacs-devel
[Top][All Lists]
Advanced

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

Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installe


From: Philip Kaludercic
Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS
Date: Wed, 26 Oct 2022 18:48:04 +0000

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

> Philip Kaludercic [2022-10-26 15:28:04] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> It can be done, but I believe it would be best to add those kinds of
>>>> annotations to the server side (elpa-admin.el).  The issue is that
>>>> figuring out what version was used to release a package is non-trivial
>>>> using just vc.
>>>
>>> FWIW, the more I think about it, the more I think `package-vc` should
>>> always use Git locally (regardless of the VCS used upstream).  This will
>>> also make it easier to share the code with `elpa-admin.el` (e.g. to
>>> figure out which commit is the latest release).
>>
>> I am not sure about that, this would break the contribution workflow for
>> anyone interested in sending back patches to a non-Git project.
>
> AFAIK this is sufficiently hypothetical that I'm really not convinced
> it's worth the extra work (and the risk of incompatibilities between
> the `elpa-admin.el` behavior and that if `package-vc`, e.g. where they
> might disagree on which commit is "the" release).

I don't know, to me this sounds more like an argument against merging
elpa-admin.el and package-vc.el...

> We can try to add some support for other local-VCS afterwards, but it
> shouldn't be a priority.

So you would say that the support for other VCS should be removed?

> Also, AFAIK the `git-remote-hg` adapter and the `git-remote-bzr` adapter
> are bidirectional, so they are still compatible with some workflows.

Fair enough.



reply via email to

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