I don't quite get the use-package package. I thought of it as a replacement of the older require statement in config files but on github it reads
This loads in the package XYZ, but only if XYZ is available on your system
So do I have to ensure that I have the package before?
Because sometimes it seems, all I need is the use-package statement for a fresh Emacs install to get the dependency.
Please clarify.
I think the point is to let you share your init.el across systems and simply have it ignore packages which are not available on any particular system.
It also appears to allow you to specify, but defer the evaluation of, your own customizations for any package you use until the package is actually loaded, so unlike require, it doesn't force you to load a package you are not going to use in this session.
There is a facility for requiring a package to be installed if it's not installed; look for the :ensure keyword and the use-package-always-ensure configuration variable in the documentation.
I generally write code by logging on to a remote machine (typically AWS). I have a fairly big list of packages that I use and a fairly large .emacs.el. While I can quickly install emacs on nay remote machine, I am looking for a way to "package" my emacs and house it somewhere so that I can quickly install it on any machine I login to. Whats the best way to do this?
First you would obviously bundle everything into source control (except for a private file). Bitbucket and Gitlab offer private repos.
You can see this wiki for a way to list all the needed packages in your init file. (this is actually used by Prelude)
Then I see some options.
Use Cask
Some use Cask to manage package dependencies, some do not
The Cask file lists all dependencies:
(depends-on "cask")
(depends-on "dash")
(depends-on "evil")
Use org-mode
Some write their config in org-mode and load it with a call to org-babel, which is doable in one line in ~/.emacs.d/init.el:
(require 'org)
(require 'ob-tangle)
(org-babel-load-file (expand-file-name "~/.emacs.d/myemacs.org"))
Split your config in multiple files
and some split it in multiple elisp files.
Here some nice configs worth taking inspiration from:
Noahfrederick uses org-mode and Cask: https://github.com/noahfrederick/dots/tree/master/emacs.d
Purcell uses multiple elisp files where each require the needed package: https://github.com/purcell/emacs.d/tree/master/lisp
In init-elpa.el, he defines a function that takes a package in argument and installs it if it is not present:
(defun require-package (package &optional min-version no-refresh)
"Install given PACKAGE, optionally requiring MIN-VERSION.
If NO-REFRESH is non-nil, the available package lists will not be
re-downloaded in order to locate PACKAGE."
(if (package-installed-p package min-version)
t
(if (or (assoc package package-archive-contents) no-refresh)
(package-install package)
(progn
(package-refresh-contents)
(require-package package min-version t)))))
and in every file, he uses:
(require-package 'dired+)
Also commit the installed packages
And for your config to install quicker, you may add the installed packages into source control too. That way you can also ensure to have identical environments.
I always recommend putting the entire ~/.emacs.d under version control, including all packages and other libraries.
It's a bit more hassle, and maybe a bit messier, but if you want to guarantee the state of the configuration every time you install it somewhere new, you need to have a complete copy.
Using version control is my firm preference, because that makes it trivial to revert changes to packages, etc. So if you upgrade a package and Emacs breaks, it's a single step to put things back they way they were (and doing so doesn't require you to remember how they were).
With this approach the act of cloning a single repository is all that is required to obtain a working system in a known state; and it limits your dependence upon the availability, consistency, and permanence of remote sources to just that one repository (and if you have it locally, or even carry a copy with you, you have no remote dependencies at all).
That said, lots of people don't bother and don't experience any issues, so it's not a critical point for most people.
It would be helpful if you clarified a little more what you mean by "any" computer. It sounds like emacs already installed on the machine and you just want to configure emacs to use your packages and settings. Do you have physical access to the machine or network from which you could load files from a memory stick? If not, can you access cloud storage?
My own setup looks like this:
I have a Windows 7 machine at work and Linux Mint at home.
I have a dropbox account that holds all my emacs configuration files and packages. This dropbox account is synchronized to a local folder on each machine and my .emacs file on each computer is only one line:
(load-file "~/Dropbox/dotemacs.el")
I often tweak package files and configurations. Using dropbox keeps my settings synchronized across all computers.
If you can't install Dropbox, you could manually sync to cloud storage like git.
check https://github.com/redguardtoo/elpa-mirror,
create your own repository on a usb memory stick, it's stable because all the package versions are the version you are already using for a very long time.
That's the quickest way, basically you can get your setup on any machine in 1 min.
As the README for my repo emacs for rails devs says it is as easy as pushing your ~/.emacs.d contents to github and on the target machine:
Install emacs using homebrew (chances are you are on OS X) brew install emacs --HEAD --use-git-head --cocoa --srgb
Git clone your repo to ~/.emacs.d/
Boot emacs
If there is magic, it's using the built in package manager with ELPA and marmalade and having that check to see if packages are installed and if not, install them.
Works for me and my boxes & servers.
el-get goes a long way in helping achieve a portable emacs configuration setup. The idea is to declare the packages you want in the emacs config file, push that file to a repo, and pull it on all the computers where you want an identical emacs configuration. This is how the code might look in elisp:
(setq my-packages (append '(el-get switch-window yasnippet ...)
(mapcar 'el-get-source-name el-get-sources)))
(el-get 'sync my-packages)
el-get will make sure that the packages get automatically installed and properly initialized. However, my understanding is that when you dereference a package, it doesn't get uninstalled. And if you uninstall it manually, you'll have to do it across all the computers, also manually. In other words, el-get goes only half the way in achieving a truly portable solution. My question is if anybody has written elisp code that will uninstall the packages just by dereferencing them in init.el? Or whether I should look elsewhere for a fully portable declarative dependency management solution for emacs?
I'm answering myself here because in the end I opted for an alternate solution.
phils' answer is still valid, but I found it troublesome to have the .emacs.d directory under version control, and to be fair I didn't want to bother with fake submodules.
What I did instead: I contacted el-get's maintainer, Dimitri, and presented him with the problem.
Dimitri said:
I could see us adding an el-get-cleanup function that you would have to call with the current list of packages and that would el-get-remove any package already installed locally but not on the provided list.
(el-get-cleanup my-packages)
You could then use that from your user-init-file if you want to, or do
that as a routine every now and then.
With his guidance, I then wrote the function in question.
(defun el-get-cleanup (packages)
"Remove packages not explicitly declared"
(let* ((packages-to-keep (el-get-dependencies (mapcar 'el-get-as-symbol packages)))
(packages-to-remove (set-difference (mapcar 'el-get-as-symbol
(el-get-list-package-names-with-status
"installed")) packages-to-keep)))
(mapc 'el-get-remove packages-to-remove)))
Ah, the joys of open source...
(See also my blog post)
You should use el-get in conjunction with some form of version control. That provides the portability, so that when you remove a package and commit the result to your repository, the package will also be uninstalled for the other instances once they have pulled those changes.
If you are leaving the package files to el-get to manage, then those files may still exist on the other copies after the package is removed from one instance but, provided that el-get's status and autoload files are in your repo, I think the state of each package should be correct.
Personally, I recommend committing all files to your repository after installing a package. That way when you remove a package, commit the changes, and pull those changes from another instance, both copies are in the same state.
Moreover, I would never trust the availability, consistency, or permanence of a remote source when it comes to setting up a new instance of my Emacs configuration -- the act of cloning my repository is all that should be required to obtain a working system.
So: use el-get for installing and updating packages, and use version control to make it portable.
Is it possible to remove built-in Emacs packages like "tetris"? They can't be marked to be deleted in package list as of 24.1. It would be nice to have a minimal installation of Emacs - even though barely useful - by deleting some or all built-in packages. Is it possible to do somehow, and will this ability added in future?
Emacs should start and be useable even if the whole lisp directory is empty (note that we rarely/never test it, so I don't guarantee that it'll work, but at least in principle it should and if it doesn't you should report it with M-x report-emacs-bug). So feel free to remove any and all packages in there you don't find useful, in order to create a trimmed-down version of Emacs.
You could just remove the elc files of all of the packages you want.
For example, in the version of emacs located in the ubuntu repository the tetris package is located in:
/usr/share/emacs/23.3/lisp/play/tetris.elc
If you move or remove it, emacs will continue to work, but you won't be able to play tetris anymore.
You might want to inspect the package--builtins variable. That said - there is little sense in removing any packages installed via package.el since package.el extracts and loads automatically only a package's autoloads - therefore having many installed packages doesn't result in any significant overhead. I'm quite certain that removing built-in packages will never be a feature of package.el.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Although several thousand Emacs Lisp libraries exist, GNU Emacs, until version 24.1 did not have an (internal) package manager.
I guess that most users would agree that it is currently rather inconvenient to find, install and especially keep up-to-date Emacs Lisp libraries.
Pages that make life a bit easier
For versions of Emacs older than 24.1:
Emacs Lisp List - Problem: I see dead people (links).
Emacswiki - Problem: May contain traces of nuts (malicious code).
Emacsmirror - The package repository I am working on. Problem: No package manager supports it natively yet.
Some package managers
It's not that nobody has tried yet. (Some of these did not exist when this question was asked.)
auto-install
borg.el - Assimilate Emacs packages using Git submodules.
el-get.el - Supports many sources.
elinstall.el
epackage aka DELPS - Debian packaging concepts applied to Emacs Lisp packages.
epkg.el - This is now just a tool for browsing the Emacsmirror.
install.el
install-elisp.el
jem-pkg.el
package.el - ELPA. Seems like it will be included in Emacs 24.
UPDATE -- package.el is included in GNU Emacs, starting with version 24.1
pases.el
pelm - Command line installer; using php.
plugin.el
straight.el - Recent and experimental, has not reached 1.0 release yet.
use-package.el
XEmacs package manager
package has been included in the Emacs trunk. epkg is not ready yet and also currently not available. At least install-elisp, plugin and use-package do not seem to be actively maintained anymore.
I have created a git repository containing all these package managers as submodules.
Some utilities that might be useful
Package managers could use these utilities and/or they could be used to maintain a mirror of packages.
date-calc.el - Date calculation and parsing routines.
ell.el - Browse the Emacs Lisp List.
elm.el, elx.el, xpkg.el - Used to maintain the Emacsmirror.
genauto.el - Helps generate autoloads for your elisp packages.
inversion.el - Require specific package versions.
loadhist.el, lib-requires.el, elisp-depend.el - Commands to list Emacs Lisp library dependencies.
project-root.el - Define a project root and take actions based upon it.
strptime.el - Partial implementation of POSIX date and time parsing.
wikirel.el - Visit relevant pages on the Emacs Wiki.
Discussions about the subject at hand
emacs-devel 20080801
comp.emacs 20021121
RationalElispPackaging
The question (finally)
So - I would like to know from you what you consider important/unimportant/supplementary etc. in a package manager for Emacs.
Some ideas
Many packages (the Emacsmirror provides that largest available collection of packages, but there is no explicit support in any package manager yet).
Only packages that have been tested.
Support for more than one package archive (so people can choose between many/tested packages).
Dependency calculated based on required features only.
Dependencies take particular versions into account.
Only use versions that have been released upstream.
Use versions from version control systems if available.
Packages are categorized.
Packages can be uninstalled and updated not only installed.
Support creating fork of upstream version of packages.
Support publishing these forks.
Support choosing a fork.
After installation packages are activated.
Generate autoload files.
Integration with Emacswiki (see wikirel.el).
Users can tag, comment etc. packages and share that information.
Only FSF-assigned/GPL/FOSS software or don't care about license.
Package manager should be integrated be distributed with Emacs.
Support for easily contacting author.
Lots of metadata.
Suggest alternatives before installing a particular package.
I am hoping for these kinds of answers
Pointers to more implementations, discussions etc.
Lengthy descriptions of a set of features that make up your ideal package manager.
Descriptions of one particular desired/undesired feature. Feel free to elaborate on my ideas from above.
Surprise me.
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.
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.
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.
So far, a much improved ELPA seems the way to go.
I once spent some time writing a small package manager for Emacs.
http://gmarceau.qc.ca/plugin.el
I wrote:
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.
You will need two library files to get it to run, loop-constructs.el and record.el
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.