I once had Melpa in my list of elisp repositories; I recently removed it after realizing that its version numbers surely had to be on a completely different scale than those of the other repos (eg Marmalade, the normal Elpa)...therefore when using U to "Mark Upgradable Packages", the version of every package that existed in both Melpa and another repository would always be the Melpa version, just because the Melpa repo version #s are ridiculously high.
Example 1: The available Marmalade version of abl-mode is 0.9.0. The available Melpa version of the same package is... 20130607.917?!
Example 2: The available Marmalade version of flex-autopair is 0.3. The available Melpa version of the same package is 20120809.2118... Something's up.
I wouldn't be concerned if it weren't for the fact that this means that what the Emacs package manager thinks is the most recent version...may not be the most recent version. Since Melpa (which has some awesome packages that other repos don't, btw) is obviously using a different numbering/versioning system... I just can't include it in package-archives anymore. Is there some kind of package that fixes this/translates the Melpa version numbers to normal ones and makes Melpa compatible with the other repos?
The version numbers represent the date when each package was pulled from its repository.
There's an issue on the github page explaining this further.
It's also possible to exclude certain packages from a specific archive. Read here to see how
I wouldn't worry too much about your emacs being fooled into downloading an old version. The cool thing about Melpa is that (for most packages) it automatically pulls the most recent version of each package from its source repository (typically git). So it's very unlikely a package will be outdated.
Related
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.
I maintain a fairly well-used emacs package (ido-ubiquitous), and in the next version I plan to drop support for Emacs 23 and below. People who use Emacs 23 and below will be able to continue using the current version of my package.
However, I don't want to have Emacs 23 users upgrading via ELPA or git or something else and ending up with the new version that isn't compatible with their emacs. Is there a generally accepted way of handling this gracefully? Do I have any choice short of renaming the new version to "ido-ubiquitous-ng" or something?
ELPA/package.el
To prevent updates via package.el, add the special dependency (emacs "24.1") to the Package-Requires list. See Library Headers in the Emacs Lisp Manual, in the description of the Package-Requires: header:
[…] The package code automatically defines a package named ‘emacs’ with the version number of the currently running Emacs. This can be used to require a minimal version of Emacs for a package.
The package.el which is distributed independently for Emacs 23 and below does not provide this special package. Thus, any attempt to install your package on Emacs 23 will fail with a message complaining about “emacs” being unavailable for installation, leaving the old, compatible version in place.
However, when using this, be prepared to handle complaints from users of Emacs 24. Many users apparently do not delete their old package.el when upgrading to Emacs 24. Thus the old package.el overrides the new built-in one, leading to spurious errors on installation.
ELGet
I do not know Elget. Probably ask its author for help in this matter.
Git submodules, Tarballs and other legacy methods
I do not think, that you can really prevent updates, if users install your package in a legacy way (e.g. Git submodules, distribution packages, etc.). You can only complain after your package was updated, which is arguably too late, because the incompatible code is now already there.
You may choose to add an explicit version check, with a detailed error. I consider this superfluous, though. If you really go for Emacs 24, you will be using incompatible functions, so your package won't load successfully, whether you explicitly prevent it or not. So save yourself of superfluous code :)
TL;DR (+ personal experience)
First of all, please do not rename your package. Few users can follow the news on each and every installed package. Thus many users will not immediately realize that the package was renamed, and continue to use an outdated version without notice or warning. Effectively, you would sort of punish Emacs 24 users of your package.
Add the special dependency to prevent accidental updates via package.el. Add prominent documentation, that your package requires Emacs 24, like in the first section of your Github Readme. Then, let the matter rest. Anything else is likely more hassle that it is worth.
In my personal experience, Emacs users are not stupid (well, at least the majority isn't). They read documentation. They understand documentation.
Users of Emacs 23 know that their Emacs is outdated. Many of them expect incompatibilities and breakage. If the package suddenly breaks for them, they will seek advice on Github, realize that the package is not available for Emacs 23 anymore, and either go back to the last working release, or (hopefully) upgrade their Emacs.
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.
Where do I find haskell-mode-2.8 for emacs .tar? I cant find the download anymore...
You can also get it from the marmalade package repository where it's called haskell-mode.
You can also get the handy ghc happy haskell mode package.
And, if you don't want to mess about with package managers - they are both available on Github as well:
haskell-mode on GitHub
ghc-mod on GitHub
Seems that it was removed from the official repository. Anyway, you can download it from some package repository. For example: http://ftp.ucr.ac.cr/FreeBSD/ports/amd64/packages/elisp/haskell-mode-2.8.0.tbz (Note: haskell-mode is in pkg/share/emacs/sit-lisp/haskell-mode)
How do I submit updates of packages that I use to the ELPA? Can someone provide an example of how to prepare paredit-22, for example, to put onto the ELPA?
I think that one of the reasons that ELPA isn't getting many package submissions is that there is still little known about the official ELPA repository(http://elpa.gnu.org/) that will be setup for Emacs 24(which will have ELPA built-in). Without guidelines most people would probably rather wait than duplicate their efforts. There is also a lot of controversy surrounding ELPA - most about its inability to update packages automatically which makes a lot of users question its value at all. I, personally, favor distribution packages over something like ELPA, but not everyone is using GNU/Linux and even there not everyone would agree with me.
The ELPA website explains exactly what to do:
http://tromey.com/elpa/upload.html
To contribute to GNU ELPA, you must sign FSF copyright assignment papers and then follow the instructions to upload your package.
Alternatives for ELPA are Marmalade and MELPA, which have huge repositories and are immensely popular among Emacs users.
Marmalade requires registration on the website, after which you can upload your package. Because Marmalade requires manual uploading of packages, it usually provides stable versions. Read instructions for uploading.
MELPA works differently from Marmalade. Usually you store your package online in some version control system, then you register it through MELPA's GitHub page, and MELPA regularly automatically synchronizes with it, so MELPA users always have access to the bleeding edge version of the packages. As of March 2015 it has >2300 packages. Read instructions on how to upload your package to MELPA.
You can look onto el-get, if you want to use bleeding edge packages...