New isolated `bibtex-completion` package shadowed by older versions shipped with `helm-bibtex` and `ivy-bibtex`
Closed this issue · 4 comments
Some ORB users encountered weird issues when installing the package about bibtex-completion-find-note-functions not being defined (e.g. zaeph/org-roam-bibtex/issues/27). Installing the latest version of bibtex-completion did not solve the problem for everyone, and after investigating in emacs -q, I think I've figured it out.
The problem was that an older version of helm-bibtex or ivy-bibtex was in the load-path (elpa) which caused their version of bibtex-completion to be loaded instead of the isolate package we now ship.
I think it'd be wise to let users know about this, but I'm unsure was to the best course of action. Warning users in our README.md is a given, but we might want to be more proactive with our versioning system, and implement checks that would warn the user if the version of the other package is too old.
Hm, not sure I want to go there. We make this really easy for users by offering packages on MELPA. If a user chooses to install by hand, aren't they responsible for making sure everything works? The thing is that once users start installing stuff manually, there are so many possible sources of problems (since helm-bibtex has many dependencies) that I doubt we can catch all of them. Am I being too pessimistic?
Having said that, if there is an easy way to check that at least bibtex-completion is the latest version, I'm okay with that. Would it be enough to bump the bibtex-completion version number to 1.0.1 and to require that in helm/ivy-bibtex? package.el would warn if bibtex-completion was too old, but my understanding is that we're concerned about users who don't use pacakge.el.
Am I being too pessimistic?
No, I think that's valid. It's just that I'm often guilty of not keeping my packages up to date, especially the ones which I only use rather than tweak.
I doubt we'll be going through a similar split in the future, I think we can just keep this in mind if any weird issue about undefined symbols crops up.
I'm going to close this for now, but will keep in mind. If you stumble on some easy and reliable way to manage dependencies (that's not using package.el), let me know. It's very well possible that something exists and I just don't know about it.