-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please stop bundling third-party libraries #5
Comments
url-dav is not an external library but part of core Emacs. The bundled version is only for users of older Emacsen. All of this is explained in the README, by the way. |
BTW, opening over 50 issues with essentially the same text could be considered spamming. |
Could you please consider that I am not doing that to, I don't know, trick people into giving me money or something. On the contrary I invest countless hours into cleaning up the Emacs ecosystem. It's not very exiting work and I don't get payed for doing it. Once in a while someone thanks me for doing it, but that's all I get in return. Also sometimes someone writes a comment like yours - fortunately that doesn't happen very often, still it does hurt. Back to the technical aspect: url-dav being a built-in package doesn't make it less important to prevent shadowing the upstream (here GNU Emacs) version. One might argue that it is even more important in this case. It is nice of you that you do something for the benefit of people using older Emacsen but the point I was trying to get across is that it actually does more harm than good. So my suggestion is still that you protect users of newer Emacsen from accidentally shadowing the built-in library with the version bundled with your package (which might be outdated, if it is not now it is very likely it will be at some point in the future). |
This is a github repository with some Emacs code in a state which you could consider 'alpha'. It is not meant to be some official package and it is also not meant to be packaged by someone else. In fact, this code will probably end up in Org contrib, but only when it is sufficiently stable. This repository will then be deleted. |
Okay I will remove it from the mirror then. Apology accepted, I am glad you did not mean it the way I received it. I felt bad because I didn't expect my effort to be considered spamming. I do understand why that perception isn't complete non-sense, still you could probably have said it in a nicer way. What put me off was probably that the reply was very short (and given the information I had at that time, missed the point) but at the same time you put some effort into noticing that I have opened 50 such issues. Anyways, what else could I do? There are 50 repositories each having a very similar issue. How should I get these issues fixed without pointing them out to the maintainers? Should I write a different text for each of the opened issues? Should I use a generic but much shorter text (In which case some people would not understand it, and I would have to explain it over and over again)? Should I write Emails so that they don't notice that they are not the only one getting this message? Or should I decide that because greater N packages are affected there is nothing that can be done about it, without becoming a spammer? I really can't think of a better way of doing it, than what I did. |
Oh, and I am sorry too. |
I agree that shipping libraries which might shadow newer versions is a bad thing, and if I'd actually /release/ org-caldav, I'd never put url-dav.el in a tar.gz or similar. Likewise if I'd put the code up on GNU ELPA, MELPA or some other package repository. So we are in agreement here. |
Put link to Emacs repository in Readme instead (issue #5).
Anyway, I removed url-dav now. This was something I had to do eventually anyway, so why not now? ;-) |
Thanks a lot! Have a nice one. |
org-caldav 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:
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.
org-caldav bundles at least the following libraries:
Best regards,
Jonas
The text was updated successfully, but these errors were encountered: