Re: Proposal for 'package-isolate' command

[Philip Kaludercic <philipk@posteo.net>]

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?

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

> Thanks.