[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for 'package-isolate' command
From: |
Thierry Volpiatto |
Subject: |
Re: Proposal for 'package-isolate' command |
Date: |
Fri, 18 Aug 2023 12:43:59 +0000 |
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
signature.asc
Description: PGP signature
- Re: Proposal for 'package-isolate' command, (continued)
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/17
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/17
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/17
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/17
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/18
- Re: Proposal for 'package-isolate' command, Eli Zaretskii, 2023/08/18
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/18
- Re: Proposal for 'package-isolate' command,
Thierry Volpiatto <=
- Re: Adding package and package-vc to ELPA, Philip Kaludercic, 2023/08/18
- Re: Adding package and package-vc to ELPA, Thierry Volpiatto, 2023/08/19
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/20
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/20
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/20
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/20
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/20
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/20
- Re: Changes to make in elpa-packages file for nongnu elpa, Eli Zaretskii, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa, Philip Kaludercic, 2023/08/16