php-mode available from ftp.gnu.org. install? (y/n)
，然后它会为我安装并加载 php-mode。 那会让我很开心。
I'm still learning Emacs, so I haven't had a chance to look into package managers, but a great feature would be to inform the user that the package is available if they try to use it but it's not on their system. For example, I wanted to edit a PHP file on a server once, and I tried
M-x php-mode
and Emacs was all like
M-x php-mode [no match]
when it should have been like
php-mode available from ftp.gnu.org. install? (y/n)
and then it would have installed and loaded up php-mode for me. That would have made my day right there.
I'd love to see a standard, central, and single Emacs package manager. Right now, I'd put my money on ELPA, but there is still a long way to go.
The biggest thing that would help an Emacs package manager would be to make it super trivial to publish packages. In my opinion, I'd like to see this happen in combination with a version control system like git on a central hosted platform like GitHub -- something that would make it easy for authors to publish their packages and would make it easy for others to contribute back.
Similar to how GitHub (used to) make it easy to publish RubyGems, I'd like to see something similar in an Emacs package manager. For example, tag your repository with "vX.Y.Z" and have your elisp goodness automatically available to all.
The added benefit of using a popular backend like GitHub is that you'd immediately get a lot of exposure which should help drive its success.
What I expect most is that everything useful is on it, and works well. This requires you (or a team of maintainers) to aggressively pursue packaging everything for it, and doing whatever that involves — emailing every author of a useful package, and so on.
For instance, the reason Debian (and its derivatives: Ubuntu etc.) is so good is that you can happily use your system without ever having to install something outside the repositories, and that everything on it is thoroughly tested. The actual features of the package manager are important, but secondary to the managed packages themselves.
Easy configuration synchronization: I, like many people, use Emacs on many different computers and servers, some of them my own and some not. It would be amazing if the package manager had some sort of file which I could transfer from one computer to another; then, on the latter computer, the package manager would bring my Emacs into the state I like it in -- all the packages installed and configurations set. Combined with the ability to be able to easily install either site-wide (if one has root permissions) or as a single user, I could synchronize all of Emacsen everywhere.
I'm nearly positive that the best solution involves submitting more packages to ELPA and adding multi-source support to package.el. The Emacs maintainers have said that they would consider including package.el in version 24 as long as it pointed to an FSF repository by default.
Of course, submission also needs to be an automated process too; the current method of mailing the ELPA maintainer only works on a small scale.
No matter how this is done, the most important thing in my opinion is that it should be trivial to submit packages to the repository. At the same time, we do not want those packages to be instantly available, to guard against malicious code(and due to licensing issues). Unless there is a "trust" system in place, based on crypto signatures.
Also useful:
"metapackages", to install several packages at once.
In the same way, we should be able to install a set of elisp files, for maintainability
"Broken" packages should not be allowed to disrupt Emacs startup. This is easy and I have it implemented in my own .emacs
Ability to install files other than scripts. This is often overlooked, but very useful. You'd be able to, for instance, ship images, for icons, toolbars, etc.
Versioning:package X requires package Y > 1.0
Testing: perform basic sanity checks, testing for conflicts (keybindings, function redefinitions, functions that are expected to be present but aren't, etc).
BUG TRACKING: I can't stress the importance of this enough. Having a centralized place to report package bugs (and being able to track them) is extremely important to assure the quality of the packages.
Some sort of compressed archive seems to be best to do some of the above.
Plugin is my attempt at creating a
package manager for Emacs. Plugin
will automatically downloads Emacs
extensions, unpacks them in a
directory, adds that directory to the
load-path, generates auto-load
annotations, and modify your dot-emacs
file. The auto-load annotations are a
little-known feature of Emacs. Once
they are generated, Emacs extensions
load quickly and incrementally, which
is really nice if you have as many
extensions installed as I do.
I think the hackers for the iPhone got quite close to what I want, as does Ubuntu's "apt".
I like to be able to:
add
remove (package only)
remove user settings
view documentation
upgrade ( after reading the change log)
add new archive ( aka add repository )
see dependencies
see version
search for name, keyword
browse by (date added, date modified, name)
save all installed packages & settings
load set of packages & settings
I would like a main set of things that all work nicely and are the recommended way of doing whatever. Then a global set where everything working gets in. Then the ability for anyone to host their own archive.
It would be nice if this was all tied into git/svn/whatever so that you could install old versions. Make your own patches by forking off etc etc etc....
Besides the mentioned above, i expect something like debian, and other repositories - set of the stable, experemental, untested packages. Ability to add my own repositories - i use lot of the packages directly from VCS, so it could be useful to create my own packages
I think that the package manager should take a lot of inspiration from Rubygems. I also think that it should have a site like Gemcutter.
A central repository could also be nice (like Emacsmirror). This however may not be necessary if a site like Gemcutter exists that collects all packages.
I think these things are important for this to work.
Central location of some kind that collects all packages
Easy to add packages
Easy to maintain packages
Easy to contribute to other packages
Easy to install, uninstall and update packages
Possibility to add package dependencies
Common structure for all packages
So a package manager like Rubygems with a site like Gemcutter and a central repository like Emacsmirror (preferably on Github because of it's social coding) would do Emacs really good.
All in all I think that much inspiration should be taken from Rails and how Rails handles Gems.
I don't know how fresh this question is...
but the model I would like to see is CPAN. I also don't know Rubygems but it sounds similar to CPAN.
CPAN is a perl archive + library management system. When I need to write a perl program that requires... FTP or SOAP or JSON or XML or ZIP, or...etc, I can run the CPAN package manager, select the requisite package for download, view and verify the dependencies, then install everything. CPAN is mirrored .."everywhere".
CPAN works wonderfully for my purposes, and something similar for emacs would be nice to have. It also supports building C/C++ code on demand.
That's what I would like to see in emacs.
Some further comment on requirements.
explicit download of packages. No auto install. No invisible downloads. I want to ask for new libraries or new function.
I should be able to list the name/version/timestamp of installed packages.
If my friend gives me his list, I should be able to diff his emacs state against mine.
check-for-updates function. What updates are available? What do they fix?
depedency checking, verification, and download. If I install csharp-mode and it requires v5.0.28 of cc-mode, then it should confirm with me, that I must also download cc-mode.
there should be some sort of community ranking of these packages, like ranking torrents on isohunt. I want to see if a package has 3 upvotes or 3000.
"transactional" behavior. If an install goes boom, it must unwind to a last-known-good state.
failsafes. If I've put custom mods in linum.el, it should refuse to install a new version over my changes, unless I explicitly allow it. It should warn me before even starting. Do this with checksums/md5's over the existing install.
have the option of running some packages from compressed archives, like zip files. So I never have any doubt that I have not updated any of the embbedded elisp.
ability to use mirrored hosts for package distribution.
all this function should be accessible through M-x library-manageemnt or something.
Finally, it would be nice to have a way to segregate or organize libraries of functions. Hierarchical namespaces. Emacs' flat namespace is very dated. This is sort of independent but complementary to the core function of package management. I'm not a lisp guru so I don't know how hard this would be; maybe there is already a way to do it.
Package managers don't offer anything I value w.r.t. single-file elisp packages with simple dependencies: adding and deleting from site-lisp has never caused problems. It's packages that depend on external programs (e.g., ispell), multi-file packages (e.g., auctex, org-mode) that can be tricky. Can't think of any single-file elisp package with nontrivial dependencies, offhand.
For these, short of a package manager, I'd like emacs' elisp-packages to acquire test suites which can be run en masse, and which provide useful information in the event of dependency failures.
发布评论
评论（12）
我仍在学习 Emacs，所以我还没有机会研究包管理器，但一个很棒的功能是通知用户，如果他们尝试使用该包但它不在他们的系统上，则该包可用。 例如，我想在服务器上编辑一次 PHP 文件，我尝试了
一下，Emacs 一切都像
它应该的那样
，然后它会为我安装并加载 php-mode。 那会让我很开心。
I'm still learning Emacs, so I haven't had a chance to look into package managers, but a great feature would be to inform the user that the package is available if they try to use it but it's not on their system. For example, I wanted to edit a PHP file on a server once, and I tried
and Emacs was all like
when it should have been like
and then it would have installed and loaded up php-mode for me. That would have made my day right there.
通过版本控制自动发布
我希望看到一个标准的、集中的、单一 Emacs 包管理器。 现在，我会把钱放在 ELPA 上，但还有很长的路要走。
对 Emacs 包管理器有帮助的最重要的事情就是使发布包变得非常简单。 在我看来，我希望看到这种情况与像 git 这样的版本控制系统结合在像 GitHub —— 可以让作者轻松发布他们的包，并让其他人轻松做出贡献。
与 GitHub（过去）如何轻松发布 RubyGems 类似，我希望在 Emacs 包管理器中看到类似的东西。 例如，用“vX.YZ”标记您的存储库，并让所有人自动使用您的 elisp 优点。
使用 GitHub 等流行后端的额外好处是，您会立即获得大量曝光，这将有助于推动其成功。
Automatic publishing from version control
I'd love to see a standard, central, and single Emacs package manager. Right now, I'd put my money on ELPA, but there is still a long way to go.
The biggest thing that would help an Emacs package manager would be to make it super trivial to publish packages. In my opinion, I'd like to see this happen in combination with a version control system like git on a central hosted platform like GitHub -- something that would make it easy for authors to publish their packages and would make it easy for others to contribute back.
Similar to how GitHub (used to) make it easy to publish RubyGems, I'd like to see something similar in an Emacs package manager. For example, tag your repository with "vX.Y.Z" and have your elisp goodness automatically available to all.
The added benefit of using a popular backend like GitHub is that you'd immediately get a lot of exposure which should help drive its success.
我最期望的是一切有用的东西都在上面，而且运行良好。 这要求您（或维护人员团队）积极追求为其打包所有内容，并做任何涉及的事情 - 向有用包的每个作者发送电子邮件，等等。
例如，Debian（及其衍生品：Ubuntu 等）之所以如此优秀，是因为您可以愉快地使用您的系统，而无需在存储库之外安装任何东西，并且其上的所有内容都经过彻底的测试。 包管理器的实际功能很重要，但相对于受管理的包本身来说是次要的。
What I expect most is that everything useful is on it, and works well. This requires you (or a team of maintainers) to aggressively pursue packaging everything for it, and doing whatever that involves — emailing every author of a useful package, and so on.
For instance, the reason Debian (and its derivatives: Ubuntu etc.) is so good is that you can happily use your system without ever having to install something outside the repositories, and that everything on it is thoroughly tested. The actual features of the package manager are important, but secondary to the managed packages themselves.
轻松配置同步：我和许多人一样，在许多不同的计算机和服务器上使用 Emacs，其中一些是我自己的，有些不是。 如果包管理器有某种我可以从一台计算机传输到另一台计算机的文件，那就太棒了； 然后，在后一台计算机上，包管理器将使我的 Emacs 进入我喜欢的状态——安装所有包并设置配置。 结合能够轻松地在站点范围内安装（如果具有 root 权限）或作为单个用户安装的能力，我可以在任何地方同步所有 Emacsen。
Easy configuration synchronization: I, like many people, use Emacs on many different computers and servers, some of them my own and some not. It would be amazing if the package manager had some sort of file which I could transfer from one computer to another; then, on the latter computer, the package manager would bring my Emacs into the state I like it in -- all the packages installed and configurations set. Combined with the ability to be able to easily install either site-wide (if one has root permissions) or as a single user, I could synchronize all of Emacsen everywhere.
我几乎肯定，最好的解决方案包括向 ELPA 提交更多包并向 package.el 添加多源支持。 Emacs 维护者表示，他们会考虑在版本 24 中包含 package.el，只要它默认指向 FSF 存储库。
当然，提交也需要是一个自动化的过程； 当前向 ELPA 维护者发送邮件的方法仅适用于小规模。
I'm nearly positive that the best solution involves submitting more packages to ELPA and adding multi-source support to package.el. The Emacs maintainers have said that they would consider including package.el in version 24 as long as it pointed to an FSF repository by default.
Of course, submission also needs to be an automated process too; the current method of mailing the ELPA maintainer only works on a small scale.
无论如何完成，我认为最重要的是向存储库提交包应该很简单。 同时，我们不希望这些软件包立即可用，以防止恶意代码（并且由于许可问题）。 除非有一个基于加密签名的“信任”系统。
也很有用：
某种压缩存档似乎最适合执行上述某些操作。
到目前为止，经过大幅改进的 ELPA 似乎是最佳选择。
No matter how this is done, the most important thing in my opinion is that it should be trivial to submit packages to the repository. At the same time, we do not want those packages to be instantly available, to guard against malicious code(and due to licensing issues). Unless there is a "trust" system in place, based on crypto signatures.
Also useful:
Some sort of compressed archive seems to be best to do some of the above.
So far, a much improved ELPA seems the way to go.
我曾经花了一些时间为 Emacs 编写一个小型包管理器。
http://gmarceau.qc.ca/plugin.el
我写道：
您将需要两个库文件才能运行它， loop-constructs.el 和record.el
I once spent some time writing a small package manager for Emacs.
http://gmarceau.qc.ca/plugin.el
I wrote:
You will need two library files to get it to run, loop-constructs.el and record.el
我认为 iPhone 的黑客已经非常接近我想要的了，Ubuntu 的“apt”也是如此。
我希望能够：
我想要一组主要的东西，它们都能很好地工作，并且是推荐的做任何事情的方式。 然后是一个全局集合，所有工作都可以进入。然后任何人都可以托管自己的存档。
如果这一切都绑定到 git/svn/whatever 中，这样您就可以安装旧版本，那就太好了。 通过分叉等等等等来制作你自己的补丁......
I think the hackers for the iPhone got quite close to what I want, as does Ubuntu's "apt".
I like to be able to:
I would like a main set of things that all work nicely and are the recommended way of doing whatever. Then a global set where everything working gets in. Then the ability for anyone to host their own archive.
It would be nice if this was all tied into git/svn/whatever so that you could install old versions. Make your own patches by forking off etc etc etc....
除了上面提到的之外，我还期望 debian 和其他存储库之类的东西 - 一组稳定的、实验性的、未经测试的软件包。 能够添加我自己的存储库 - 我直接使用来自 VCS 的许多软件包，因此创建我自己的软件包可能很有用
Besides the mentioned above, i expect something like debian, and other repositories - set of the stable, experemental, untested packages. Ability to add my own repositories - i use lot of the packages directly from VCS, so it could be useful to create my own packages
我认为包管理器应该从 Rubygems 中获得很多灵感。 我还认为它应该有一个像 Gemcutter 这样的网站。
中央存储库也可能很好（例如 Emacsmirror）。 然而，如果存在像 Gemcutter 这样收集所有包的站点，则可能没有必要。
我认为这些事情对于这项工作的开展非常重要。
因此，像 Rubygems 这样的包管理器带有一个站点像 Gemcutter 和像 Emacsmirror 这样的中央存储库（最好在 Github 上，因为它是社交编码）会让 Emacs 做得非常好。
总而言之，我认为应该从 Rails 以及 Rails 如何处理 Gems 中获得很多灵感。
I think that the package manager should take a lot of inspiration from Rubygems. I also think that it should have a site like Gemcutter.
A central repository could also be nice (like Emacsmirror). This however may not be necessary if a site like Gemcutter exists that collects all packages.
I think these things are important for this to work.
So a package manager like Rubygems with a site like Gemcutter and a central repository like Emacsmirror (preferably on Github because of it's social coding) would do Emacs really good.
All in all I think that much inspiration should be taken from Rails and how Rails handles Gems.
我不知道这个问题有多新鲜......
但我希望看到的模型是 CPAN。 我也不知道 Rubygems，但听起来和 CPAN 很相似。
CPAN是一个perl档案+图书馆管理系统。 当我需要编写一个需要... FTP或SOAP或JSON或XML或ZIP等的perl程序时，我可以运行CPAN包管理器，选择下载所需的包，查看并验证依赖关系，然后安装一切。 CPAN 被镜像......“无处不在”。
CPAN 非常适合我的目的，如果 emacs 拥有类似的东西那就太好了。 它还支持按需构建 C/C++ 代码。
这就是我想在 emacs 中看到的。
一些对要求的进一步评论。
最后，如果有一种方法来隔离或组织函数库就好了。 分层命名空间。 Emacs 的平面命名空间已经非常过时了。 这与包管理的核心功能是独立的，但又是互补的。 我不是 lisp 大师，所以我不知道这有多难； 也许已经有办法做到这一点了。
I don't know how fresh this question is...
but the model I would like to see is CPAN. I also don't know Rubygems but it sounds similar to CPAN.
CPAN is a perl archive + library management system. When I need to write a perl program that requires... FTP or SOAP or JSON or XML or ZIP, or...etc, I can run the CPAN package manager, select the requisite package for download, view and verify the dependencies, then install everything. CPAN is mirrored .."everywhere".
CPAN works wonderfully for my purposes, and something similar for emacs would be nice to have. It also supports building C/C++ code on demand.
That's what I would like to see in emacs.
Some further comment on requirements.
Finally, it would be nice to have a way to segregate or organize libraries of functions. Hierarchical namespaces. Emacs' flat namespace is very dated. This is sort of independent but complementary to the core function of package management. I'm not a lisp guru so I don't know how hard this would be; maybe there is already a way to do it.
包管理器不提供任何我看重的具有简单依赖关系的单文件 elisp 包：从
site-lisp添加和删除从未引起问题。 依赖于外部程序（例如 ispell）的包、多文件包（例如 auctex、org-mode）可能会很棘手。 无法立即想到任何具有重要依赖关系的单文件 elisp 包。对于这些，缺少包管理器，我希望 emacs 的 elisp-packages 获取可以集体运行的测试套件，并在依赖项失败时提供有用的信息。
Package managers don't offer anything I value w.r.t. single-file elisp packages with simple dependencies: adding and deleting from
site-lisphas never caused problems. It's packages that depend on external programs (e.g., ispell), multi-file packages (e.g., auctex, org-mode) that can be tricky. Can't think of any single-file elisp package with nontrivial dependencies, offhand.For these, short of a package manager, I'd like emacs' elisp-packages to acquire test suites which can be run en masse, and which provide useful information in the event of dependency failures.