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

[Philip Kaludercic]

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

> Philip Kaludercic [2022-10-30 14:15:07] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I guess so.  Here is a possible patch that should behave close enough to
>>>> elpa-admin.el using "blame"
>>>
>>> Why do you use `blame` rather than `log` like `elpa-admin.el`?
>>
>> I tried to use log like in elpa-admin.el, but the issue was I had to
>> either
>>
>> 1. Define the generic interface to search for a line using a regular
>>    expression that is not an Elisp regular expression, and could
>>    conceivably differ between different VCS that might also implement
>>    'last-change'.
>>
>> 2. Deal with the issue that the Version header might move between
>>    revisions, meaning that a line range wouldn't do a good job at
>>    capturing the right commit.
>
> FWIW, I suspect that your `git blame` will give the same answer as the
> corresponding `git log` (it will probably end up using the same code
> under the hood), but I don't understand what you mean above.  I think
> `git log` would accept the exact same `-L` as you use for `git blame`
> and will deal with "the issue that the Version header might move" in the
> exact same way.

Well apparently not, but I am not entirely sure what the issue was.  If
you want to, I could take a better look at it and figure out if I missed
something.

>>> Hmm... the code I see in your patch uses `vc-region-history` (which is
>>> only supported for Git and Hg, currently, and is fairly difficult to
>>> support in a generic way) rather than `vc-annotate`.
>>> Am I missing something?
>>
>> Uh, that is my mistake.  I started writing that code yesterday (I
>> believe?) and simply forgot what I had used.  I'll try to translate that
>> into vc-annotate before pushing anything.
>
> [ Just to be clear, I wasn't implying a preference between `vc-annotate`
>   and `vc-region-history`.  As fallback, they both seem fine to me.  ]

I think vc-annotate is preferable, as it is more widespread.

>> Checking out a specific revision is currently only done right after
>> cloning, so this is always a reset.  The issue here is that I am trying
>> to stay generic and was using 'vc-retrieve-tag' (but perhaps
>> 'vc-checkout' would be better), so this is an issue that might have to
>> be tackled in vc-git.el...
>
> I find this part of VC beyond repair: AFAICT the notion of
> "tag/snapshot/..."  has been defined "on the fly" with a narrow view of
> what was needed for one particular situation at a particular time.
>
> It's probably worth "throwing it out" (well, keeping it on life support)
> and introducing a whole new set of operations based on a design that
> tries to accommodate all the various related notions out there.

I agree, but that issue goes beyond the proposal of feature/package+vc.