Please stop bundling third-party libraries
tarsius opened this issue · comments
jump is mirrored on the Emacsmirror, which is a large up-to-date collection of Emacs packages.
As the maintainer of the mirror I am trying to resolve feature conflicts that result from one package bundling libraries from another package. I suspect in most cases these libraries were included so that users would not have to find, download and install each dependency manually.
Unfortunately bundling also has negative side-effects: if the bundled libraries are also installed separately, then it is undefined which version actually gets loaded when the respective feature is required.
Initially that isn't a big problem but in many cases upstream changes are not included or only after a long delay. This can be very confusing for users who are not aware that some of the installed packages bundle libraries which are also installed separately. In other cases bugs are fixed in the bundled versions but the fixes are never submitted to upstream.
Also now that Emacs contains the package.el package manager there is a better way to not require users to manually deal with dependencies: add the package (and when that hasn't been done yet the dependencies) to the Melpa package repository. If make is required to install your make you might want to add it to the el-get (another popular package manager) package repository instead.
Alternatively if you want to keep bundling these libraries please move them to a directory only containing bundled libraries and add the file ".nosearch" to that directory. You can then load the library using something like this:
(or (require 'bundled nil t)
(let ((load-path
(cons (expand-file-name "fallback-libs"
(or load-file-name buffer-file-name)
load-path))))
(require 'bundled)))
Of course if your version differs from the upstream version this might not be enough in which case you should make an effort to get your changes merged upstream.
jump bundles at least the following libraries:
- findr
- inflections
- which-func
Best regards,
Jonas
Thanks for the pointers, Jonas. Well done for proactively working to clean up the elisp ecosphere; I've been doing the same thing as part of managing Melpa.
The bundling here in jump.el is legacy cruft, and I'm happy to tidy it up when I get chance.
Cheers,
-Steve
Good to hear (again) that there are other janitors around :-)
One question though: do you also first try to get upstream to make the necessary changes or do you fork right away and use the fork for melpa? I have recently started doing the latter (the patched branch in the Emacsmirror repository of mirrored packages) but only if upstream just doesn't reply... after several months and pings. I think we get the most out of the cleanup work like this if we try hard to get the changes into upstream.
uh wait... are you maintaining this package now, but still in Eric's repository?
We never fork for Melpa, and if forks (or even lookalike packages) are submitted to us, we don't accept them until an effort has been made to get fixes merged upstream.
Yes, I'm maintaining this and rinari. And also nex3's haml-mode. I should really move those repos to my own github account.
So regarding Melpa, we don't maintain any library code ourselves -- all the recipes point at either SCM repositories elsewhere, or elisp on the emacswiki.
Please let me know when you move the repositories so that I can more easily update the repository I pull from. (If you forget that isn't a big problem either, as it will show up as an import failure which I will then investigate. (Yes I should automate that...))
I thought that I have seen some forks from the Melpa maintainers that were used to build the Melpa packages. Guess I was wrong and these were only temporal forks to get a fix merged into upstream (which was the actual repo being imported).
You should however be aware that some users do create forks and then have those forks imported into Melpa. I think it would be a good idea to keep a list of such packages that are imported from forks. If you have such a list already I would be interested in seeing it.
Yes, we look out for such forks. When I receive new recipes, I try to figure out whether the submitted repo is the original one, or a fork.
BTW, this repo (jump.el) is the canonical source of inflections.el.
findr.el has been modified here to fix its doc headers, so those changes should get pushed back to the upstream version (on emacswiki, I believe).
What about which-func.el - it's a built-in library?
The other package providing inflections is emacs-rails, which I, as I just noticed, have previously moved to the Emacsattic instead of the mirror. (Unfortunately I did not add a note about the reason for that move when I did it as I usually do. But I assume it has to do with the last commit being 5 years old.)
What makes you think which-func.el is bundled here? It's not present in this repo.
And yes, the other inflections.el had been neglected, then was bundled here and fixed/improved.
Cheers,
-Steve
I don't know :-) Probably was bundled with the old version.
Anyways thanks for taking care of this.