Re: Proposal for 'package-isolate' command

[Thierry Volpiatto <thievol@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 4147 bytes --]


Philip Kaludercic <philipk@posteo.net> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> Forget it, it is working properly, just forget you had modified
>>>> package--dependencies as well.
>>>> Sorry for the noise.
>>>
>>> It was either that or a new function had to be added, not sure which
>>> approach is worse.  The current implementation seems to have been
>>> hastily added by Lars last year, and it is a bit regrettable in
>>> retrospect.  It would be possible to modify my change, and have the
>>> function always return package-desc objects, since the function is only
>>> used in one other spot in another part of the file.  While there might
>>> be others (packages or individuals) that depend on the function behaving
>>> the way it does, but on the other hand, convention designates it as
>>> being an "internal" function.
>>
>> The actual version is something like 4 or 5 lines long, so external
>> packages can inline this version under another name if really needed,
>> but your version is covering the both so it's ok I think.
>> OTOH The problem with package.el is inconsistency within its functions,
>> sometimes you have to use a pkg-desc as arg, sometimes not, sometimes
>> functions return a list of symbols sometimes a list of pkg-desc, what is
>> a package name, a string or a symbol? What is a pkg-desc exactly,
>> sometimes it is the cdr in other places the cadr is used...
>> Also built-in packages don't have the same format unless they are distributed
>> in Elpa etc...
>
> Right, there is certainly work to be done.
>
>>>> Some packages seems to require a specific version of a package for their
>>>> dependency e.g. seq, by excluding it the package may not work correctly,
>>>> this is my understanding but I may be wrong. Also perhaps the package
>>>> e.g. seq is selected later when computing dependencies but maybe user
>>>> wants to select a particular version manually in the first place?
>>>
>>> The current algorithm should pick the first package in the package alist
>>> that satisfies the necessary dependencies.  Perhaps that should be
>>> re-thought or the selection should be more clever, e.g. if the user
>>> explicitly specifies a dependency with a version, then it should be
>>> preferred to whatever other dependency might be determined, at the
>>> possible expense of triggering runtime bugs.
>>
>> I think it is hard to cover all cases, but after all it is more a
>> developer tool for debugging a particular package than a end user tool
>> to run packages, so perhaps the developer can give directives about
>> dependencies to use when needed.
>>
>> Another thing, you use actually 
>>
>>     (expand-file-name invocation-name invocation-directory)
>>
>> I suggest you use the truename of this instead as emacs can be symlinked
>> in some installations.  It should work with the symlink name, but it is
>> clearer which emacs version is used.
>
> I second Eli's question here, what difference would it make?  Clearer to
> whom?

OK, this is not that important.

>> Now your function is working fine and nearly finish, did you think how
>> you are going to distribute it? It seems you are going to merge it in
>> master, but what about providing it as well as a Elpa package so that
>> users of old emacs (at some point of course, say emacs-27) can use it to
>> report bugs?
>
> I am not a fan of small ELPA packages, but what I'd like to bring up
> again was the proposal to add package.el itself to ELPA.  I wrote a
> patch in <873559q83j.fsf@posteo.net> that should arrange everything
> necessary for this move, there are still a few points that should be
> discussed in terms of stability and recovering from a possibly
> inconsistent state.  I think I'll create a feature branch some day soon
> to make the proposal more concrete.

Ok, looking forward for having a package-isolate function fetchable for
everybody, I will use my own version that fit my needs as a helm action
for its package manager.

Thanks for your work.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]