MELPA No Longer Distributes Packages from Emacswiki

By Xah Lee. Date: . Last updated: .

controversy.

@sanityinc Announcement: MELPA no longer distributes insecure packages pulled Emacswiki. https://github.com/melpa/melpa/pull/5008

one of the old lisper, Drew Adams, author of dired+ bookmark+ icicle etc, usually fairly complex and big packages, is hard-hit with this. Am not sure what's his status.

some of the old lispers, i knew them for over 10 years, and i kept thinking, at anytime, they'll depart this earth. Counting myself.

Drew Adams, is an oddball. (lots oddballs in emacs sphere) I recall, his packages use unusual version numbering (that u've never seen), and 3 of them. And he refuse to change. He's also extremely into 1 buffer per window (emacs frame).

Drew is active at emacs overflow (last time i checked, must be 3 or 4 months ago), so active that he mostly do meta edit now instead of answering, cuz otherwise for every single question he'd had a hand in answering. He's also very active at emacs dev list, and emacswiki.

in past 20 years i know of, anytime a UI issue comes up in emacs dev, a flame feast erupts. Drew is of course in every one of them, as many emacs devs are. Drew is one of the more vocal. Some of his view, i side with, some, bizarre.

but in emacs dev list, it's not unusual, to see idiotic and out of this world bizarre opinions on emacs UI/Tech issues. Many are from regulars. Yet, note that they often do not agree with each other, it is not like if they are all bizarre but in same way.

basically, the emacs people are the fringes of society. Emacs attracts them, and they grow emacs. Not just fringe opinions on tech, but life style and outlook.

i could go on and give a profile of half of the regulars by name, extempore, now. Am not certain that's a good thing. But note, a few of them, their opinions on emacs, i consistently do not like. While some, i consistently like, eg Stephen Monnier in general.

also note, Alex (aka kensanata), the creator of emacs wiki, a top name in emacs during 2000s, is opposed to this. But now, he's old, faded, even emacswiki has been driven to uselessness due to change in society. Younger coders runs the show.

Drew's Response

So, here's response from Drew. Not a happy one.

Someone posted the issue on reddit. And after some comment, Drew made a comment, here:

https://www.reddit.com/r/emacs/comments/7vocqa/update_on_melpa_removing_emacswiki_packages_they/dtuhzmt/

Here's what Drew said, copied from above:

  1. I, Mr. “Stubborn Author”, continue to upload my Emacs-Lisp libraries to (admin-locked pages on) Emacs Wiki. Call me whatever you like. (I prefer “lazy”.)
  2. I have no objection if someone mirrors that code in a GIT (or other) repository (what MELPA has decided to stop doing).
  3. I do naturally object if someone forks it, i.e., does not continue to mirror it as I maintain it but instead makes their own changes to it.
  4. I can't prevent that - the GPL allows it. But I do object to it.
  5. It's one thing to fork something because it is no longer being maintained. It's another thing to do so while it is being carefully and actively maintained, especially by its original author.
  6. Just because the GPL allows someone to do that, that doesn't mean that it is right to do so.
  7. I intend to continue to maintain my code, and I would appreciate it if anyone who propagates my code sends its users directly to me with their comments and bug reports.
  8. Any maintainer of a 3rd-party package that uses any of my libraries can also just copy (download) the code from Emacs Wiki at any time. If they do that periodically then they benefit from my maintenance (bug fixes, enhancements).
  9. It should go without saying, but: It is good if someone who mirrors my code looks it over, including updates (something not done by MELPA, BTW).
  10. So far, this is the case only for highlight.el. It is mirrored in that way here:
  11. https://github.com/steckerhalter/highlight.el
  12. The same should be the case, IMO, for anyone making use of any 3rd-party code, whether or not it is maintained using GIT and is digitally signed: They should look over the code they're using, including updates.
  13. It is also good, IMO, for end users of Emacs-Lisp code to look at it - any such code from anywhere, including from MELPA.
  14. I prefer that users of my code know some Lisp and appreciate the code not just for what it does (how it helps them) but also for the code itself.
  15. Those are users who (a) ask good questions, (b) offer good suggestions, and (c) can be inspired to write their own, even better, libraries. With my code being on Emacs Wiki I expect I'll continue to get such users.
  16. I don't really care to have masses of users who don't care about the code. Informed and interested users make for more interesting communication with me, including better bug reports. They make me glad if I can inspire them, and they inspire me. Emacs is just a hobby for me - I'm not selling anything.
  17. The Emacs package system makes it easy for users to download, update, and load/activate a library, which is good. And it makes it easy for an author to bundle multi-file libraries, which is also good.
  18. I'm certainly glad that package.el and package repositories such as MELPA exist. Good things.
  19. But with that ease of use can come a certain danger (yup) of not becoming acquainted with what it is that one is using. There are likely some people who download from MELPA without a clue about reading Emacs Lisp.
  20. Digital signing does not protect users from dangers that can come from using something with no clue about what it does or how it does it.
  21. Lisp can be powerful stuff. It is harmful or negligent to let someone get the impression that just because they get something from a package repository it is somehow safe.
  22. I'm all for encouraging people to use Emacs and take advantage of volunteer code. I'm not in favor of people doing so blindly or giving them the impression that it is safe to do so as long as they get the code from a “Certified Dealer”, so to speak.
  23. I would just as soon not have people blindly use my code (or anyone else's). At least a cursory glance at it and some understanding of Emacs Lisp are in order.
  24. I typically put a lot of effort into the Commentary part of my Lisp libraries, as well as into code comments, the names of functions, etc. I expect a user of a library to read the Commentary, at a minimum.
  25. The “old-school” model of someone downloading code from the wiki (or another site), putting it in their load-path, and requireing it has the advantage of ensuring, to some degree, that the user has at least some clue about Lisp and Emacs.
  26. The package system and MELPA can perhaps make it too easy for users who pay no attention, or are oblivious or careless, to make use of code.
  27. (No, I'm not claiming that most MELPA users are oblivious, and I'm not claiming that just because someone might know how to use require and load-path they are safe. Not at all.)
  28. A writer of Lisp code that uses another library should be able to tell whether the latter code looks OK or is fishy. If it doesn't pass the smell test then it shouldn't be used.
  29. It's bad enough for someone to use code for herself that she doesn't understand. It's far worse to, in effect, package such code with another library and distribute it to others.
  30. (I'm speaking generally here about packaging, not saying anything about specific packages.)
  31. Another alternative for a maintainer of a 3rd-party library that uses one of my libraries is to use a replacement library to accomplish what is needed. Especially if someone uses only a small part of what a given library offers, that can make sense.
  32. I have no problem with that, obviously. I don't sell my code. If it helps someone, great; if not, too bad.
  33. If Emacs Wiki gets branded as something only for “advanced” or Lisp-knowledgable or pay-attention users, that's OK by me.
  34. So much the better. That's what should be the case: pay attention - you'll get more out of it.
  35. If you use Lisp code you are using Lisp. You should respect the code and respect the fact that Lisp can do nearly anything. And you should take advantage of free access to the source code to take a look at it. You're being given more than just a black box that might do something useful.
  36. So IMO should MELPA, like Emacs Wiki, be only for pay-attention users. Folks should not let themselves be lulled to sleep in the confidence that code on MELPA is particularly benign.
  37. Whether or not there is a real danger in using code from Emacs Wiki (no problem has ever been reported AFAIK, even from unlocked pages), there is perhaps some danger from propagating overconfidence in an ELPA repository that does not audit updates.

Drew, I sympathize with your points. However, note that, time has moved on.

Package system is good thing, but it appears, direct consequence is brainless users and bloat. No, nobody looked at source code. (well, some, like 1% probably.)

Since emacs has package system, after a few years, it acquired the condition of javascript npm, where, any joe who dunno donkey would require a package of 5 lines of code.

but what can you do? Society in general, moves that way, more specifically, software industry been that way for a decade now, with keywords of "helping" and "positive". Emacswiki, is really not the right place for code repository.

We could have code repo that's not just brainless dump and bloat and users. But how to achieve that, is anybody's opinion and guess and rant.

Just take some time to create a github account and put your packages there. Once done, the maintenance isn't worse than uploading to emacs wiki.

Either that, or, your packages get even less users. Your packages, are already losing most users even 10 years ago, since they are complex, big, with quaint documentation.

but, you probably don't care. Yes, that's right, old generation die out. And i think this is a perfect illustration.

you want users to know some emacs lisp before using a package?

    ┈╱╱▏┈┈╱╱╱╱▏╱╱▏┈┈┈
    ┈▇╱▏┈┈▇▇▇╱▏▇╱▏┈┈┈
    ┈▇╱▏▁┈▇╱▇╱▏▇╱▏▁┈┈
    ┈▇╱╱╱▏▇╱▇╱▏▇╱╱╱▏┈
    ┈▇▇▇╱┈▇▇▇╱┈▇▇▇╱┈┈