3 ms·

The package manager appears to be yet another single-app ghetto. From the docs: > Note that for some packages, package.el requires you to have an external tar

The package manager appears to be yet another single-app ghetto. From the docs: > Note that for some packages, package.el requires you to have an external tar program. My platform already has a package manager that knows whether I have tar, and it will quietly go get that as soon as I install anything that needs it. If package.el can't take advantage of a system that already works, it's part of the problem rather than the solution.

kiiski 17y ago
Emacs is cross-platform. It would be kinda hard for them to start using system specific package managers (remember that windows exists too). And anyway, this is meant for installing emacs extensions, not software for whatever system you're using.
- JulianMorrison 17y ago
  The proper solution would be 1. Standardize the package format (say, a directory containing this-and-that). 2. Standardize where the packages go for personal and root installation. 3. Have an emacs package manager, that deliberately does not use its own metadata, but always uses the implied metadata of the packages in their locations. 4. Therefore, it doesn't matter what tool put the packages in place, so long as they are in place. 5. So use the built in package manager, or apt, or rpm, or whatever you prefer.
  - kiiski 17y ago
    But how would that solve the problem of automatic cross-platform installation of a tool required by the emacs package? As I see it, the problem is in automating step 5. I guess you can find out the installed package manager in linux somehow and then call it, but how are you going to do that in windows?
    - JulianMorrison 17y ago
      I think you misread what I was getting at. In this scenario Emacs doesn't call the package manager - if emacs manages packages it does it for itself in elisp. But it doesn't matter to emacs whether the package was installed from an elisp program or from a .deb file, because the end result (predefined format in predefined place) is the same regardless. So you're free to use, or not use, the package manager of your choice. Or mix them.
abrahamsen 17y ago
From an Emacs package maintainers point of view, is that your platforms package manager is just another single-system ghetto. And most likely not the ghetto I live in. What I need is a package format that only relies on software that is available to every Emacs user, no matter what set of device drivers and associated utilities they have running under their editor. So I can give a single set of instructions, I can actually test out myself. But a standardized Emacs package format should make life easier for the people maintaining the single-system package managers, making it easier to import Emacs packages into their respective ghettos.
- prodigal_erik 17y ago
  Sure, there's no reason not to standardize the information you give to the people who package your code for a given platform. But package.el makes it easier for users to smuggle code onto the filesystem whose version and dependencies aren't announced to the package manager and which may have never even been tested on the platform, and I regard that as a bad idea. Our sysadmins certainly don't want to go back to the world where every app had its own way of handling plugins and they had to understand all of them.

kiiski 17y ago

Emacs is cross-platform. It would be kinda hard for them to start using system specific package managers (remember that windows exists too). And anyway, this is meant for installing emacs extensions, not software for whatever system you're using.

JulianMorrison 17y ago
The proper solution would be 1. Standardize the package format (say, a directory containing this-and-that). 2. Standardize where the packages go for personal and root installation. 3. Have an emacs package manager, that deliberately does not use its own metadata, but always uses the implied metadata of the packages in their locations. 4. Therefore, it doesn't matter what tool put the packages in place, so long as they are in place. 5. So use the built in package manager, or apt, or rpm, or whatever you prefer.
- kiiski 17y ago
  But how would that solve the problem of automatic cross-platform installation of a tool required by the emacs package? As I see it, the problem is in automating step 5. I guess you can find out the installed package manager in linux somehow and then call it, but how are you going to do that in windows?
  - JulianMorrison 17y ago
    I think you misread what I was getting at. In this scenario Emacs doesn't call the package manager - if emacs manages packages it does it for itself in elisp. But it doesn't matter to emacs whether the package was installed from an elisp program or from a .deb file, because the end result (predefined format in predefined place) is the same regardless. So you're free to use, or not use, the package manager of your choice. Or mix them.

abrahamsen 17y ago

From an Emacs package maintainers point of view, is that your platforms package manager is just another single-system ghetto. And most likely not the ghetto I live in. What I need is a package format that only relies on software that is available to every Emacs user, no matter what set of device drivers and associated utilities they have running under their editor. So I can give a single set of instructions, I can actually test out myself. But a standardized Emacs package format should make life easier for the people maintaining the single-system package managers, making it easier to import Emacs packages into their respective ghettos.

prodigal_erik 17y ago
Sure, there's no reason not to standardize the information you give to the people who package your code for a given platform. But package.el makes it easier for users to smuggle code onto the filesystem whose version and dependencies aren't announced to the package manager and which may have never even been tested on the platform, and I regard that as a bad idea. Our sysadmins certainly don't want to go back to the world where every app had its own way of handling plugins and they had to understand all of them.