Re: feature/package-vc has been merged

[Philip Kaludercic]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> From my pov if you use the package directly from the version control
>>> system you need to take these specialties into account.
>>> Source isn't used as is but processed by the packages build-system.
>>> But the user also needs to take not that all the necessary tools such as
>>> make or ninja are installed.
>>
>> Right, this is currently not supported.  Theoretically for security
>> reasons, but security and packaging in Emacs have rarely been mutual
>> considerations.  Adding it wouldn't be difficult, but coming up with a
>> sensible fallback strategy might be.
>
> Without such a system the package could be without use in many cases.

Many is probably the word of contention here.  If you take a look at
elpa.git:elpa-packages, you'll find only a few :make or :shell-command
directives, none of which are critical.  nongnu.git:elpa-packages has
non at all.  One thing I worry about, but which has also been discussed
here are :renames.  E.g. Vertico uses these to move extensions from a
subdirectory to the main directory for packaging.  But moving the files
would be registered by the VCS, and could make committing changes more
difficult.  Maybe we could create symbolic/hard links instead of
renaming?

> I noticed recently that some external packages such as projectile where
> copied but not to the extend or why that they are useful.

I am afraid I don't understand the issue you are describing.  Could you
be more concrete?

> For example Borg only works because of magit, epkg is almost useles
> without Borg.

Just to clarify, I have never used Borg, straight, elpacaa, etc. so I
don't know how they work, how they are used or what terminology they
use.  I have peeked into their source code in the past, but none of that
was related to the development of package-vc.

> If the packages complete use case isn't meat it should at least get all
> the features that it is useful without applying hacks so it can be used
> in the next Emacs version.
> I understand that you try to get it closer however that would then only
> affect anything after Emacs 29.

What hacks are you referring to?  Is there a specific use-case you think
must be added for package-vc to be satisfactory?

> Br,
>
> Björn