Re: feature/package-vc has been merged

["Björn Bidar" <bjorn.bidar@thaodan.de>]

Philip Kaludercic <philipk@posteo.net> writes:

> 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?
In side the repositories on source tree.

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

More complex packages have a configure/prepare step, generate some lisp
code, build native parts. In the case of borg you can just add
additional steps to for example in my case build the emms libtag helper
that isn't build if you use melpa.

But you addressed that in an earlier comment. 

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

There might be reasons for that..
Quite often the core packages aren't as good or just to
complicated/convoluted with legacy features.

Or in case of borg compared to package-vc deeper integration into git or
other different features like building packages in a second instance
with just borg and the package.