12 ms·

The Sorry State of Emacs Lisp Package Archives

86 points by jaseemabid 12y ago

unhammer 12y ago
I suggested a possible solution to the author of package.el: make it so when you install a package "foo" from archive "bar", you install "bar/foo", not just "foo". On updating, you should only get updates of "foo" from the "bar" repository. If "fie" comes along with a newer version, that's ignored. If you try explicitly installing "fie/foo", you're asked to remove "bar/foo" since that's a conflict. As it is, I only use one non-ELPA repo to avoid the mess that results from enabling more repos. I would prefer to use e.g. melpa stable, but it supports only git packages, which means many of my favourites are left out.
Expez 12y ago
I haven't counted the number of packages I use, from MELPA, but it's likely around 100. I have problems associated with MELPA about 2-3 times per year. One of these times was yesterday, when cider-test was added to cider. Melpa excludes files ending with -test.el by default, so a file was missing. I grabbed the file manually from github and went on with my evening. An hour or so later the pull request fixing the problem was merged. For developers, the criticism against MELPA is just FUD. If anything goes wrong you can fix it easily enough.
- lvh 12y ago
  I agree that MELPA is mostly a good thing. However, even if the software there works fine, that doesn't address the criticisms of MELPA that the author talks about in his article: version numbers, rebuild times, effort and abuse to add a stable designated version. (The author of the article makes elpy, an excellent Python development environment, where occasionally, a component gets modernized. This is the case right now with the refactoring logic. MELPA gives you a broken elpy, joergen has no reasonable way to override it even for people who also subscribe to his personal package index, etc. :-))
broodbucket 12y ago
Things could be better, but I don't feel anything's completely broken. As a user, it's awesome having a built-in package repository. Sure, ELPA by itself is pretty useless, but everything feels pretty good. package.el is also still relatively new, as far as emacs is concerned.
paddyoloughlin 12y ago
Does anyone know of a good "get up and running with emacs" style tutorial which includes setting up of package management/repositories aimed at the emacs newbie? The built-in tutorial is great for learning to edit with emacs, but I'm looking for something that will quickly explain the state of the nation with regard to emacs package management.
- chriswarbo 12y ago
  Complete beginners: http://ergoemacs.org/misc/list_of_emacs_starter_kits.html http://ergoemacs.org/misc/list_of_emacs_starter_kits.html http://unix.stackexchange.com/questions/6170/what-are-some-excellent-emacs-utter-beginner-resources http://unix.stackexchange.com/questions/6170/what-are-some-e... Tricks and tips for experienced users: http://whattheemacsd.com/ http://whattheemacsd.com/ General Emacs blogs and news: http://planet.emacsen.org/ http://planet.emacsen.org/
- tenfingers 12y ago
  It's important to note that, generally speaking, you don't need packages if you are an emacs newbie. I tend to generally give the same advice to vim newbies who think they absolutely need to have 10 packages to put !COLORS! to be productive. The emacs distribution comes with everything under the sun, plus the kitchen sink already. And I mean it literally. Loading more packages, without understanding elisp and/or how emacs generally work, doesn't translate to "more productivity" in my mind. That's how you would approach packages in a sane way: - you start using emacs - you start tweaking a mode that you use often - you decide the tweak is still not enough and/or you envision a better way to do things - you look up online for an alternative emacs package/mode - you install it The built-in package manager helps you only with the last step. And to be honest, there's not much that you have to do if you want to install it by hand, because at this point you should be at least familiar with elisp and emacs. Another important note: elisp packages are mostly "stale". There are some big packages which are continuously improving, but whenever I read some mode sources, I discover they were last updated years ago, and didn't really need any changes. I used to check for a couple of big packages manually on a year basis before using "package". Now I can automate the task, but I actually only update whenever I have a bug I noticed or I have time to read the full changelog. You don't want your editor to have different behavior between updates, really.
Cacti 12y ago
Compared to the past 30 years of 'package management', which basically amounted to hand copying and managing tons of files from all kinds of different sources, with all kinds of different version numbers, MELPA and package.el are absolutely incredible. Sure, there are problems, but they'll be fixed eventually.
- mih 12y ago
  Agreed. Having the package manager in built has taken away the pain of having to search the horrible 'emacswiki' for code snippets and tweaking them to get it working. It has also enabled me to try out plenty of new packages which have greatly added value to my emacs, which I would otherwise have never bothered to even try. Lots of bugs? Sure! and some aspects could do with a better user experience, but still a great improvement over prior versions of emacs.
astine 12y ago
Marmelade is my favorite Emacs package archive and I had no idea it was having such trouble. I wonder what an ordinary programmer can do to help.
mschaef 12y ago
As a long-time Emacs user, I find the presence of package managers somewhat disturbing. I'm not all that excited about fetching an elaborate dependency graph of third party plug-ins to make my editor of choice operate the way I'd like. My personal solution has been to integrate a few good packages into .emacs.d, manage that directory with git/github, and then cull out the stuff I no longer need as aggressively as I have time for. It seems to work fairly well, and has resulted in a manageable and cross platform installation. Maybe this is just me being stuck in my ways....
- jordigh 12y ago
  Me too, I eschew package managers and just put stuff in .emacs.d as I want it, and version it: http://inversethought.com/hg/dotemacs/file/b1915cf8617c/packages http://inversethought.com/hg/dotemacs/file/b1915cf8617c/pack... Like you, I'm probably stuck in my ways too. I just don't trust any package manager but Debian's apt. I also don't like this trend of having one (or more!) package managers per programming language.
- klibertp 12y ago
  > Maybe this is just me being stuck in my ways... Probably. By default Emacs is passable Elisp IDE and nothing more, really. Sure, it has a bunch of neat (disabled by default, mostly) built-in plugins (also tetris and doctor mode), but its main strength lies in how easy it is to extend and customize it. With plugins you first promote Emacs to absolutely outstanding Elisp IDE, then you get beautiful Elisp stdlib (strangely missing from core distribution) and from that point onwards you're already in editor heaven, because you can very easily install and modify every conceivable piece of functionality. Right now I have 143 packages installed with package.el, about 30 packages installed via git (and cedet via bzr, I also build Emacs from bzr repo for ease of dumping it), 3051 lines of my own Elisp scripts, one package I installed from package.el but later rewrote completely (fuzzy-find-in-project, another 423 loc), another 254 loc in custom-set-variables and dependencies on thousands of lines of Python, Ruby, JS, Clojure, C (for example the-silver-searcher, among other more standard tools) and others. The thing is, I'd probably have exactly the same Emacs config as you instead were it not for package.el. It's a scary thought for me now - going back to vanilla Emacs (I sometimes use Zile instead of Vim on remote machines) feels like I reverted to using notepad.exe, the difference is just that great. Without an easy way to install and experiment with packages I would probably install manually a few plugins I knew I wanted (because I used them before in Vim) and I wouldn't have moved forward at all. For example, there is this wonderful info+.el by Drew Adams. Take a look at its Emacs Wiki page - to install it you need to manually download and require some 5 files (which is good, modular design and should be encouraged) which is a pain by itself. I probably wouldn't install it out of laziness. Then I'd never read absolutely fabulous Emacs, Emacs Lisp, Org Mode or Fugitive (cover to cover!) Info manuals, because really, documentation in black-and-white without syntax highlighting just isn't my thing any more (my eyesight getting worse and all). In effect, my Emacs would still be just Emacs instead of being MY Emacs, and I'd probably left it sooner or later (but now I'm being vendor-locked-in with myself being a vendor for most part, which is kind of scary too ;)). The Emacs I use beats Sublime in terms of features easily and has - after a year of using it - literally thousands of little (and bigger) functions which make me more productive, more comfortable, better informed and plain happier than I'd be with vanilla Emacs. And it was package.el which enabled me to make my Emacs like this.
jzelinskie 12y ago
When I last looked at Emacs, the package systems were what really turned me off the most and made me stick to Vim. I really like the "Vundle workflow" where I simply list dependencies in my .vimrc and I can selectively update them or install them all at once. It appeared to me that if I wanted to rely on the Emacs package system, every time I install Emacs on a new machine, I would have to not only copy over my .emacs.d, but also run through the package manager and remember all my desired plugins then mark all them individually installation. Is there a better way?
- jbeja 12y ago
  (require-package '{package}), or el-get?
- profsnuggles 12y ago
  I used to use something similar to this to install my packages. (mapc (lambda (package) (package-install package)) '(dired+ zenburn-theme)) Until I saw this emacs config https://github.com/larstvei/dot-emacs/#package https://github.com/larstvei/dot-emacs/#package after which I just rm -rvf'ed my whole ~/.emacs.d and stole that.
- msbarnett 12y ago
  el-get (apt-get for Emacs packages) is really an order of magnitude better than dealing with raw ELPA et al: https://github.com/dimitri/el-get https://github.com/dimitri/el-get
- regularfry 12y ago
  I just keep my .emacs.d in git, including any installed packages. Seems to work.
donniezazen 12y ago
I started learning Emacs and then forgot what I learned after a few days. Steep learning curve is quite depressing. And then their are great IDEs like Android Studio and Qt Creator for programming and LibreOffice for writing. What would I gain if I put time and energy in learning Emacs?
- splawn 12y ago
  A great custom tailored environment that can be adapted for whatever you might need in the future. I used to balk at it because it seemed like too big of a hassle to setup such a customized system if you changed machines (so i stuck to vanilla vim), but ubiquitous version control makes this less of an issue. If you are good with vim install the evil package and you will be ahead of (some of) the curve.
  - donniezazen 12y ago
    As a beginner, I find it very comfortable to hit a few click to build an app or fast prototype using xml/layout editor and I don't see that happening in Emacs, unless I am wrong. I have recently started using Android Studio and it so quick to give you code suggestion aka code completion. It has literally reduced the amount of time I have to spend writing code by many folds. Is that possible in Emacs? Over the past few months, I have developed an opinion that Emacs is more suited for old school guys who hacked early computers. As someone who started programming with IDEs on modern computer, one isn't really aware of lackings of IDEs, if any.
    - subsection1h 12y ago
      The first editor I used was HomeSite in the mid 1990s. I eventually wanted a more powerful editor. Many programmers recommended Emacs and Vim, but their learning curves seemed too steep. I switched from HomeSite to jEdit in the late 1990s because some jEdit users argued that jEdit had the power of Emacs but without the steep learning curve. I used jEdit for a few years, but eventually I needed to program in a language for which there wasn't a good jEdit plugin available. That's when I switched to Emacs. It took me several full days to make the switch, much shorter than I expected it would, but I was far more experienced at that point than I was when I first heard of Emacs. I wish I had switched to Emacs sooner, mostly because of Org mode, which has changed my life. Even if I were to start using an IDE because of a job requirement or whatever, I would still use Emacs for knowledge management. FYI, I don't code in Java, and many people who do prefer IDEs, even some Emacs users.
edavis 12y ago
I would love to see an Emacs package management system that copies the best parts of other, already established package managers instead of creating something from scratch. Homebrew is a joy to use. APT is beautiful. Arch Linux is doing interesting things with pacman. Every scripting language that matters uses a standard, widely known packaging recipe (setup.py, Gemfile, package.json, etc.) that developers can understand in about 15 minutes. Emacs? Emacs doesn't introduce its package management system until Chapter 47 in the manual. The default repo has so few packages I thought there was an error the first time I saw it. The entire packaging ecosystem screams "this is an afterthought!" It isn't 1994 anymore. Package management may not be a "solved problem," but it isn't exactly a new problem, either. I know the Emacs shibboleth is to do everything in Emacs, but we can't be afraid of other options if they've proven themselves to be better.
- empthought 12y ago
  None of the package managers you mentioned work on Windows...
shadytrees 12y ago
I just want to quickly plug package.el, which is one of those things that make you go "Oh, yeah, that's how it always should've been done. Why didn't I think of that?"

86 points by jaseemabid 12y ago

I suggested a possible solution to the author of package.el: make it so when you install a package "foo" from archive "bar", you install "bar/foo", not just "foo". On updating, you should only get updates of "foo" from the "bar" repository. If "fie" comes along with a newer version, that's ignored. If you try explicitly installing "fie/foo", you're asked to remove "bar/foo" since that's a conflict. As it is, I only use one non-ELPA repo to avoid the mess that results from enabling more repos. I would prefer to use e.g. melpa stable, but it supports only git packages, which means many of my favourites are left out.

Expez 12y ago

I haven't counted the number of packages I use, from MELPA, but it's likely around 100. I have problems associated with MELPA about 2-3 times per year. One of these times was yesterday, when cider-test was added to cider. Melpa excludes files ending with -test.el by default, so a file was missing. I grabbed the file manually from github and went on with my evening. An hour or so later the pull request fixing the problem was merged. For developers, the criticism against MELPA is just FUD. If anything goes wrong you can fix it easily enough.

lvh 12y ago
I agree that MELPA is mostly a good thing. However, even if the software there works fine, that doesn't address the criticisms of MELPA that the author talks about in his article: version numbers, rebuild times, effort and abuse to add a stable designated version. (The author of the article makes elpy, an excellent Python development environment, where occasionally, a component gets modernized. This is the case right now with the refactoring logic. MELPA gives you a broken elpy, joergen has no reasonable way to override it even for people who also subscribe to his personal package index, etc. :-))

broodbucket 12y ago

Things could be better, but I don't feel anything's completely broken. As a user, it's awesome having a built-in package repository. Sure, ELPA by itself is pretty useless, but everything feels pretty good. package.el is also still relatively new, as far as emacs is concerned.

paddyoloughlin 12y ago

Does anyone know of a good "get up and running with emacs" style tutorial which includes setting up of package management/repositories aimed at the emacs newbie? The built-in tutorial is great for learning to edit with emacs, but I'm looking for something that will quickly explain the state of the nation with regard to emacs package management.

chriswarbo 12y ago
Complete beginners: http://ergoemacs.org/misc/list_of_emacs_starter_kits.html http://ergoemacs.org/misc/list_of_emacs_starter_kits.html http://unix.stackexchange.com/questions/6170/what-are-some-excellent-emacs-utter-beginner-resources http://unix.stackexchange.com/questions/6170/what-are-some-e... Tricks and tips for experienced users: http://whattheemacsd.com/ http://whattheemacsd.com/ General Emacs blogs and news: http://planet.emacsen.org/ http://planet.emacsen.org/
tenfingers 12y ago
It's important to note that, generally speaking, you don't need packages if you are an emacs newbie. I tend to generally give the same advice to vim newbies who think they absolutely need to have 10 packages to put !COLORS! to be productive. The emacs distribution comes with everything under the sun, plus the kitchen sink already. And I mean it literally. Loading more packages, without understanding elisp and/or how emacs generally work, doesn't translate to "more productivity" in my mind. That's how you would approach packages in a sane way: - you start using emacs - you start tweaking a mode that you use often - you decide the tweak is still not enough and/or you envision a better way to do things - you look up online for an alternative emacs package/mode - you install it The built-in package manager helps you only with the last step. And to be honest, there's not much that you have to do if you want to install it by hand, because at this point you should be at least familiar with elisp and emacs. Another important note: elisp packages are mostly "stale". There are some big packages which are continuously improving, but whenever I read some mode sources, I discover they were last updated years ago, and didn't really need any changes. I used to check for a couple of big packages manually on a year basis before using "package". Now I can automate the task, but I actually only update whenever I have a bug I noticed or I have time to read the full changelog. You don't want your editor to have different behavior between updates, really.

Cacti 12y ago

Compared to the past 30 years of 'package management', which basically amounted to hand copying and managing tons of files from all kinds of different sources, with all kinds of different version numbers, MELPA and package.el are absolutely incredible. Sure, there are problems, but they'll be fixed eventually.

mih 12y ago
Agreed. Having the package manager in built has taken away the pain of having to search the horrible 'emacswiki' for code snippets and tweaking them to get it working. It has also enabled me to try out plenty of new packages which have greatly added value to my emacs, which I would otherwise have never bothered to even try. Lots of bugs? Sure! and some aspects could do with a better user experience, but still a great improvement over prior versions of emacs.

astine 12y ago

Marmelade is my favorite Emacs package archive and I had no idea it was having such trouble. I wonder what an ordinary programmer can do to help.

mschaef 12y ago

As a long-time Emacs user, I find the presence of package managers somewhat disturbing. I'm not all that excited about fetching an elaborate dependency graph of third party plug-ins to make my editor of choice operate the way I'd like. My personal solution has been to integrate a few good packages into .emacs.d, manage that directory with git/github, and then cull out the stuff I no longer need as aggressively as I have time for. It seems to work fairly well, and has resulted in a manageable and cross platform installation. Maybe this is just me being stuck in my ways....

jordigh 12y ago
Me too, I eschew package managers and just put stuff in .emacs.d as I want it, and version it: http://inversethought.com/hg/dotemacs/file/b1915cf8617c/packages http://inversethought.com/hg/dotemacs/file/b1915cf8617c/pack... Like you, I'm probably stuck in my ways too. I just don't trust any package manager but Debian's apt. I also don't like this trend of having one (or more!) package managers per programming language.
klibertp 12y ago
> Maybe this is just me being stuck in my ways... Probably. By default Emacs is passable Elisp IDE and nothing more, really. Sure, it has a bunch of neat (disabled by default, mostly) built-in plugins (also tetris and doctor mode), but its main strength lies in how easy it is to extend and customize it. With plugins you first promote Emacs to absolutely outstanding Elisp IDE, then you get beautiful Elisp stdlib (strangely missing from core distribution) and from that point onwards you're already in editor heaven, because you can very easily install and modify every conceivable piece of functionality. Right now I have 143 packages installed with package.el, about 30 packages installed via git (and cedet via bzr, I also build Emacs from bzr repo for ease of dumping it), 3051 lines of my own Elisp scripts, one package I installed from package.el but later rewrote completely (fuzzy-find-in-project, another 423 loc), another 254 loc in custom-set-variables and dependencies on thousands of lines of Python, Ruby, JS, Clojure, C (for example the-silver-searcher, among other more standard tools) and others. The thing is, I'd probably have exactly the same Emacs config as you instead were it not for package.el. It's a scary thought for me now - going back to vanilla Emacs (I sometimes use Zile instead of Vim on remote machines) feels like I reverted to using notepad.exe, the difference is just that great. Without an easy way to install and experiment with packages I would probably install manually a few plugins I knew I wanted (because I used them before in Vim) and I wouldn't have moved forward at all. For example, there is this wonderful info+.el by Drew Adams. Take a look at its Emacs Wiki page - to install it you need to manually download and require some 5 files (which is good, modular design and should be encouraged) which is a pain by itself. I probably wouldn't install it out of laziness. Then I'd never read absolutely fabulous Emacs, Emacs Lisp, Org Mode or Fugitive (cover to cover!) Info manuals, because really, documentation in black-and-white without syntax highlighting just isn't my thing any more (my eyesight getting worse and all). In effect, my Emacs would still be just Emacs instead of being MY Emacs, and I'd probably left it sooner or later (but now I'm being vendor-locked-in with myself being a vendor for most part, which is kind of scary too ;)). The Emacs I use beats Sublime in terms of features easily and has - after a year of using it - literally thousands of little (and bigger) functions which make me more productive, more comfortable, better informed and plain happier than I'd be with vanilla Emacs. And it was package.el which enabled me to make my Emacs like this.

jzelinskie 12y ago

When I last looked at Emacs, the package systems were what really turned me off the most and made me stick to Vim. I really like the "Vundle workflow" where I simply list dependencies in my .vimrc and I can selectively update them or install them all at once. It appeared to me that if I wanted to rely on the Emacs package system, every time I install Emacs on a new machine, I would have to not only copy over my .emacs.d, but also run through the package manager and remember all my desired plugins then mark all them individually installation. Is there a better way?

jbeja 12y ago
(require-package '{package}), or el-get?
profsnuggles 12y ago
I used to use something similar to this to install my packages. (mapc (lambda (package) (package-install package)) '(dired+ zenburn-theme)) Until I saw this emacs config https://github.com/larstvei/dot-emacs/#package https://github.com/larstvei/dot-emacs/#package after which I just rm -rvf'ed my whole ~/.emacs.d and stole that.
msbarnett 12y ago
el-get (apt-get for Emacs packages) is really an order of magnitude better than dealing with raw ELPA et al: https://github.com/dimitri/el-get https://github.com/dimitri/el-get
regularfry 12y ago
I just keep my .emacs.d in git, including any installed packages. Seems to work.

donniezazen 12y ago

I started learning Emacs and then forgot what I learned after a few days. Steep learning curve is quite depressing. And then their are great IDEs like Android Studio and Qt Creator for programming and LibreOffice for writing. What would I gain if I put time and energy in learning Emacs?

splawn 12y ago
A great custom tailored environment that can be adapted for whatever you might need in the future. I used to balk at it because it seemed like too big of a hassle to setup such a customized system if you changed machines (so i stuck to vanilla vim), but ubiquitous version control makes this less of an issue. If you are good with vim install the evil package and you will be ahead of (some of) the curve.
- donniezazen 12y ago
  As a beginner, I find it very comfortable to hit a few click to build an app or fast prototype using xml/layout editor and I don't see that happening in Emacs, unless I am wrong. I have recently started using Android Studio and it so quick to give you code suggestion aka code completion. It has literally reduced the amount of time I have to spend writing code by many folds. Is that possible in Emacs? Over the past few months, I have developed an opinion that Emacs is more suited for old school guys who hacked early computers. As someone who started programming with IDEs on modern computer, one isn't really aware of lackings of IDEs, if any.
  - subsection1h 12y ago
    The first editor I used was HomeSite in the mid 1990s. I eventually wanted a more powerful editor. Many programmers recommended Emacs and Vim, but their learning curves seemed too steep. I switched from HomeSite to jEdit in the late 1990s because some jEdit users argued that jEdit had the power of Emacs but without the steep learning curve. I used jEdit for a few years, but eventually I needed to program in a language for which there wasn't a good jEdit plugin available. That's when I switched to Emacs. It took me several full days to make the switch, much shorter than I expected it would, but I was far more experienced at that point than I was when I first heard of Emacs. I wish I had switched to Emacs sooner, mostly because of Org mode, which has changed my life. Even if I were to start using an IDE because of a job requirement or whatever, I would still use Emacs for knowledge management. FYI, I don't code in Java, and many people who do prefer IDEs, even some Emacs users.

edavis 12y ago

I would love to see an Emacs package management system that copies the best parts of other, already established package managers instead of creating something from scratch. Homebrew is a joy to use. APT is beautiful. Arch Linux is doing interesting things with pacman. Every scripting language that matters uses a standard, widely known packaging recipe (setup.py, Gemfile, package.json, etc.) that developers can understand in about 15 minutes. Emacs? Emacs doesn't introduce its package management system until Chapter 47 in the manual. The default repo has so few packages I thought there was an error the first time I saw it. The entire packaging ecosystem screams "this is an afterthought!" It isn't 1994 anymore. Package management may not be a "solved problem," but it isn't exactly a new problem, either. I know the Emacs shibboleth is to do everything in Emacs, but we can't be afraid of other options if they've proven themselves to be better.

empthought 12y ago
None of the package managers you mentioned work on Windows...

shadytrees 12y ago

I just want to quickly plug package.el, which is one of those things that make you go "Oh, yeah, that's how it always should've been done. Why didn't I think of that?"