Philip Kaludercic writes: > Thierry Volpiatto writes: > >> Philip Kaludercic 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