Fix the 'Package-Requires' for the melpa

[sunlin7]

Hi,

After install the emacs-inspector from the melpa, the dependency fields missed the treeview, which is mandantory for tree-inspector.el. The inspector-pkg.el after installed from melpa, only contain the emacs-27.1.

(define-package "inspector" "20230316.161633" "Tool for inspection of Emacs Lisp objects"
  '((emacs "27.1"))
...)

This PR try to fix the issue. Please help review it, thanks.

[mmontone]

Hi. This is a problem I've refused to fix so far.

Because in my opinion this is a problem of package managers, not of the inspector packages.

I'm shipping two separate packages here. inspector.el and tree-inspector.el, and they are independent packages. tree-inspector depends on tree-view, but inspector doesn't. So I'm not willing to add tree-view as dependency of inspector, that's a problem of package managers in my view.

[sunlin7]

OK, thanks for comment, close as not a inspector package issue.

[phikal]

Inspector is currently packaged as a single package on GNU ELPA, which does not make this an issue of the package manager but the package archive. If you want to, we can arrange for the package to be split into two, one excluding the files of the other and vice-versa. That being said, this is not the preferred approach, since both elpa-admin.el (the build script for GNU ELPA) and package-vc (the fetch-sources-from-vcs extension to package.el) would handle the entire directory as a single package, as is the traditional convention. Would it be imaginable to maintain the two packages on separate branches/repositories?

[mmontone]

Maybe, maybe.. but I don't like it :) . I mean, I feel like "it is not my problem" :) It is a problem of package managers.

Emacs packages work at the file level, with dependencies appearing at the top, and features at the bottom. Why do these package managers work at the git/folder level?

Let's imagine I have a very modularizable/extensible system, I would like to have several packages (files):

• my-system-ext-A.el
• my-system-ext-B.el
• my-system-ext-C.el

Each one with its own set of dependencies. Do these package managers expect me to maintain those files in separate git repositories/branches ? Why don't the package managers work at the file level, like Emacs?

Please correct me if my thinking is wrong :)

[phikal]

Mariano Montone @.***> writes:

Maybe, maybe.. but I don't like it :) . I mean, I feel like "it is not my problem" :) It is a problem of package managers.

Perhaps we should clarify what we mean by package managers? Are you talking about package.el that installs a tarball prepared by a package archive or the entire system abstractly?

Emacs packages work at the file level, with dependencies appearing at the top, and features at the bottom.

I am not sure what you mean by this?

                                 Why do these package managers

work at the git/folder level?

Let's imagine I have a very modularizable/extensible system, I would like to have several packages (files):

• my-system-ext-A.el
• my-system-ext-B.el
• my-system-ext-C.el

Each one with its own set of dependencies. Do these package managers expect me to maintain those files in separate git repositories/branches ?

Please correct me if my thinking is wrong :)

This is certainly possible, from a technical perspective, it just not the conventional way that package management has been done.

[mmontone]

Mariano Montone @.***> writes: Maybe, maybe.. but I don't like it :) . I mean, I feel like "it is not my problem" :) It is a problem of package managers. Perhaps we should clarify what we mean by package managers? Are you talking about package.el that installs a tarball prepared by a package archive or the entire system abstractly?

I should have said 'package repositories'. I'm referring to ELPA and MELPA, for example.

Emacs packages work at the file level, with dependencies appearing at the top, and features at the bottom. I am not sure what you mean by this?

I mean this: https://www.gnu.org/software/emacs/manual/html_node/elisp/Simple-Packages.html

Why do these package managers work at the git/folder level? Let's imagine I have a very modularizable/extensible system, I would like to have several packages (files): - my-system-ext-A.el - my-system-ext-B.el - my-system-ext-C.el Each one with its own set of dependencies. Do these package managers expect me to maintain those files in separate git repositories/branches ? Please correct me if my thinking is wrong :) This is certainly possible, from a technical perspective, it just not the conventional way that package management has been done.

That's the part I complain about. If I setup a package-archive, then I don't have any problems adding my package files with its dependencies to it. But the current package repositories are incapable to point to files in git repositories, download them and add them to an archive, it seems.

That's very unfortunate. Specially since the simple-packages method above is so good and flexible! They contain everything that is needed.

That being said, I may stop complaining and make a separate branch/git repository. But I think it should something that should be fixed by package repositories.

[mmontone]

I don't understand why they get involved with git, and make it compulsory. I'd give an alternative to point to simple elisp package files. Keep a list with urls to latest versions of elisp file packages. Setup a job that downloads the package files and check and updates versions and adds to an package-archive. The package files contain everything, the versions, the docs, the dependencies, etc. I've done this for a Cuis Smalltalk package system, and it works perfectly.

[phikal]

Mariano Montone @.***> writes:

Mariano Montone @.***> writes: Maybe, maybe.. but I don't like it :) . I mean, I feel like "it is not my problem" :) It is a problem of package managers. Perhaps we should clarify what we mean by package managers? Are you talking about package.el that installs a tarball prepared by a package archive or the entire system abstractly?

I should have said 'package repositories'. I'm referring to ELPA and MELPA, for example.

Ok.

Emacs packages work at the file level, with dependencies appearing at the top, and features at the bottom. I am not sure what you mean by this?

I mean this: https://www.gnu.org/software/emacs/manual/html_node/elisp/Simple-Packages.html

Well, those are single-file packages, but packages can be more complicated as you know, and can include multiple files, where the package metadata is extracted from a main file.

Why do these package managers work at the git/folder level? Let's imagine I have a very modularizable/extensible system, I would like to have several packages (files): - my-system-ext-A.el - my-system-ext-B.el - my-system-ext-C.el Each one with its own set of dependencies. Do these package managers expect me to maintain those files in separate git repositories/branches ? Please correct me if my thinking is wrong :) This is certainly possible, from a technical perspective, it just not the conventional way that package management has been done.

That's the part I complain about. If I setup a package-archive, then I don't have any problems adding my package files with its dependencies to it. But the current package repositories are unable to point to files in git repositories, download them and add them to an archive, it seems.

As I said before, this is technically possible but it not the recommended practice. If you want to, I can adjust the GNU ELPA package recipe -- we have done so for other packages in the past -- but it would be much appreciated if packages (consisting of a set of files) could be mapped to repositories/branches.

That's very unfortunate. Specially since the simple-packages method above is so good and flexible!

That being said, I may stop complaining and make a separate branch/git repository. But I think it should something that should be fixed by package repositories.

If you have a concrete suggestion, then feel free to send your ideas to emacs-devel or the bug tracker.

Mariano Montone @.***> writes:

I don't understand why they get involved with git, and make it compulsory. I'd give an alternative to point to simple elisp package files. Keep a list with urls to latest versions of elisp file packages. Setup a job that downloads the package files and check and updates versions. The package files contain everything, the docs, the dependencies, etc. I've done this for a Cuis Smalltalk package system, and it works perfectly.

99% of all packages are developed with Git and usually require more than just one file, so this is not a problem, also it allows us to track the history/development and if necessary diverge from the upstream source if something has to be fixed.

[mmontone]

As I said before, this is technically possible but it not the recommended practice. If you want to, I can adjust the GNU ELPA package recipe -- we have done so for other packages in the past -- but it would be much appreciated if packages (consisting of a set of files) could be mapped to repositories/branches.

This is a git repository hosting two completely independent single-file packages. If it is easy to adjust ELPA to that, then fine. If not, I will separate into git repositories later.

[phikal]

Mariano Montone @.***> writes:

As I said before, this is technically possible but it not the recommended practice. If you want to, I can adjust the GNU ELPA package recipe -- we have done so for other packages in the past -- but it would be much appreciated if packages (consisting of a set of files) could be mapped to repositories/branches.

This is a git repository hosting two completely independent single-file packages. If it is easy to adjust ELPA to that, then fine. If not, I will separate into git repositories later.

It is not difficult, we just do not like doing it because it is not robust. It is based on the exclusion of all files that are not part of a repository, but this only works for tarballs and not from-source installations (for obvious reasons). You could help us out by adding an .elpaignore file to list all files that do not belong to any package, so that the package specifications only have to list the necessary files to exclude and we don't need to duplicate the common information (images, test scripts, etc.).

[mmontone]

It would be easier and more robust with an .elpainclude file if it existed. Sorry, I'm unbearable :pray: .

Ok, so I create an .elpaignore that lists things to ignore. It would only leave inspector.el and tree-inspector.el. Those are the two single-file packages that need to be included.

Then you can setup a configuration to add those as two separate packages and their distinct dependencies to ELPA.?

[phikal]

Sorry, I'm unbearable pray .

?

Then you can setup a configuration to add those as two separate packages and their distinct dependencies to ELPA?

I can do it, but again, this is under the condition that you refuse to track the separate packages in separate repositories/branches. Can you affirm that this is the case?

[mmontone]

Ok. I've moved the tree inspector to a separate git repository: https://github.com/mmontone/emacs-tree-inspector

Do I request adding to ELPA on the mailing list? Or you can take it from there?

[phikal]

I can take over from here, thank you for your cooperation.