Skip to content
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

Closed
tarsius opened this issue Jan 27, 2013 · 9 comments
Closed

Please stop bundling third-party libraries #5

tarsius opened this issue Jan 27, 2013 · 9 comments

Comments

@tarsius
Copy link

tarsius commented Jan 27, 2013

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:

(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.

org-caldav bundles at least the following libraries:

  • url-dav

Best regards,
Jonas

@dengste
Copy link
Owner

dengste commented Jan 27, 2013

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.

@dengste dengste closed this as completed Jan 27, 2013
@dengste
Copy link
Owner

dengste commented Jan 27, 2013

BTW, opening over 50 issues with essentially the same text could be considered spamming.

@tarsius
Copy link
Author

tarsius commented Jan 27, 2013

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).

@dengste
Copy link
Owner

dengste commented Jan 27, 2013

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.
I'm sorry that you're hurt, but nowhere did I imply you'd do this out of mischief. But still, I do think that posting this rather lengthy issue to over 50 github repositories is not the way to go about this.

@tarsius
Copy link
Author

tarsius commented Jan 27, 2013

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.

@tarsius
Copy link
Author

tarsius commented Jan 27, 2013

Oh, and I am sorry too.

@dengste
Copy link
Owner

dengste commented Jan 27, 2013

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.
However, I think upstream repositories are (usually) a different thing, and I wonder why you think you have to solve this issue at that high level? Maybe I'm not a typical user, but when I deliberately choose to clone code from an upstream repository, I usually do this to follow its development, report bugs and, most importantly, I pull regularly. This is very different from installing a tar.gz, where I expect the code to run fine for years to come (yes, I'm exaggerating, but not much).
I was just confused to get this issue because I don't consider this repository to be a "package", but a very volatile thing with code-in-progress, and it took me a while to understand what you mean, plus I have a nasty cold and hence am a bit cranky today...

dengste pushed a commit that referenced this issue Jan 27, 2013
Put link to Emacs repository in Readme instead (issue #5).
@dengste
Copy link
Owner

dengste commented Jan 27, 2013

Anyway, I removed url-dav now. This was something I had to do eventually anyway, so why not now? ;-)

@tarsius
Copy link
Author

tarsius commented Jan 30, 2013

Thanks a lot! Have a nice one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants