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

[Philip Kaludercic <philipk@posteo.net>]

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

>>> 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...
>
> It's not about sharing the code here (for which I have lobbied in other
> messages), but about sharing the behavior.
> `elpa-admin.el` de facto defines a "protocol" that upstream maintainers
> have to follow.  If `package-vc` doesn't follow the same protocol,
> end-users will suffer unexpected discrepancies.

That is sort of the question I was implying previously (when mentioning
adding meta data), as to whether or not there is a "protocol" or if the
two format just coincidentally share a part of a common structure.

>>> 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?
>
> Not necessarily removed, but considered second class for now.

I will have to think about it, it would be sad to have to give that up.

>         Stefan

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

>>> Do we really want to rely on the package spec for that?
>> It seems the easiest way to share this information.  Do you have a
>> different idea?
>
> Yes: use the `elpa-admin.el` code to compute that info :-)

It might be possible to use the "previous-revision" VC method to step
through the history to find the same information too... I would prefer
that to avoid a strict Git dependency.