Re: feature/package-vc has been merged

[Björn Bidar]

Philip Kaludercic <philipk@posteo.net> writes:

> 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?

Most packages work fine with if they are used in place.

>> 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?

The package is copied but not as good because in the end it misses some
features, it doesn't feel as polished. I don't have a direct example
except missing features like no build system integration.
It is just to bare bone.

>> 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.

That's to bad I think it very helpful to improve on such packages or
even just adapt them instead of reinventing them.

>> 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?

First of all I Didn't know about these elpa-packages but there are two
cases where I think custom commands could be needed such as packages with 
native modules or
some that require bootstrapping their build system by means such as
autotools.

Reunsing melpa package generation instructions just might not work as
good going by just using the package sources in place such as how borg
does it.

Br,

Björn