[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for 'package-isolate' command
From: |
Philip Kaludercic |
Subject: |
Re: Proposal for 'package-isolate' command |
Date: |
Fri, 18 Aug 2023 07:49:45 +0000 |
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.
- 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 <=
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/18
- 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