Re: feature/package-vc has been merged

[Philip Kaludercic]

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

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

What do you mean by "in place" here?

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

I am still confused as to what you are thinking about.  Setting aside
:make, :shell-command and :renames, the end experienced result of
installing a package that was prepared by elpa-admin.el or one installed
using package-vc (assuming package-vc uses the revision of the latest
release) should be identical.

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

The point of package-vc.el is to have something that explicitly extends
package.el and works in the core, in active collaboration with ELPA.
That is why the implementation is far simpler than what others have to
do, because they are fighting an up hill battle outside of the core.

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

OK, but that is something that package.el doesn't handle either right
now.  This is a shared deficit, as I had mentioned in my message to
Stefan just a few minutes ago.  I would like to address it at some
point, but probably not in time for Emacs 29.

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

I am still confused by your terminology.  Package-vc has nothing to do
with MELPA, we re-use the same package specifications that ELPA makes
use of, e.g. 
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages.