melpa installation fails

[seblemaguer]

Assuming I have this:

  (use-package org-sidebar
    :ensure t
    :commands (org-sidebar))

I have this error when I execute it:

Error (use-package): Failed to install org-sidebar: Package ‘org-ql-agenda-0’ is unavailable

the quelpa base installation works without any problem :)

[alphapapa]

Thanks, fixed in master and will be fixed on MELPA with the next rebuild.

[codemac]

This is still occurring on melpa-stable (yes I'm one of those). Any chance at a new release?

Thanks again for all your work!

[alphapapa]

@codemac Thanks for the reminder. I've tagged a 0.2 stable release.

[codemac]

Thank you! It now fails with:

Cannot open load file: No such file or directory, org-ql-view

I seet autoload references to this file, but I don't know what file it's in.

[alphapapa]

Well, this is the problem with only using MELPA Stable: Emacs package authors do not necessarily develop packages in a synchronized way, even when the relevant packages are developed by the same author (i.e. myself). org-ql-view is part of org-ql at versions 0.3-pre and greater. org-ql 0.3 is not yet on MELPA Stable (probably soon).

So I should have marked the org-ql dependency in org-sidebar 0.2 for org-ql 0.3. But 1) I forgot, and 2) 0.3 isn't even released yet, so if I had, it would fail to install because of that.

I think the bottom line is that, if you insist on only using MELPA Stable, you're going to have issues like this at times.

As an Emacs user and package developer, I don't recommend using only MELPA Stable (or maybe even at all). It is not more stable or more reliable than the plain MELPA repo. Very few package authors bother to tag stable releases, and when they do, as you can see here, it doesn't necessarily mean that the package will work better.

I tag stable releases as a way to help me track development and fixes, and it helps other packagers (like GNU Guix, etc). But I don't have a master plan that keeps tagged versions of dependencies in sync with changes. And even if I could do that, it wouldn't be worth the effort, because so few users use it (e.g. my most-downloaded package, helm-org-rifle, has only 3.5% as many downloads from MELPA Stable as it does from MELPA).

I empathize with wanting to avoid package churn, and that's why I keep my ~/.emacs.d/elpa directory in Git with the rest of my Emacs config. I update packages manually, when necessary. I can clone the entire repo to another machine and have all the same, known-working package versions everywhere. And the packages are installed from ELPA, MELPA, and a few with Quelpa directly from git--none of them are installed from MELPA Stable.

So, the bottom line is, thanks for letting me know, but it's not practical for me to fix that issue directly at this time. When org-ql 0.3 hits MELPA Stable, it should work. But I recommend changing your "package paradigm" and abandoning the exclusive use of MELPA Stable, because it doesn't actually accomplish what users think it does (e.g. it's not the MELPA equivalent of Debian Stable or Debian Testing).

[codemac]

Thank you @alphapapa for describing your reasoning. Me reporting an issue/bug is not me prioritizing it for you to fix, I know I don't have that right :)

I also keep my entire config in git as well. I use stable to not avoid package churn, but to avoid behavior churn. People make releases on a much slower cadence, and even if it's arbitrary & buggy, I don't want my setup changing too much unless it's me changing it. I use emacs for many hours a day every day, and random packages breaking my org-mode or c++-mode setups unexpectedly is not something I handle very well.

That's all irrelevant though - please just stay publishing packages the way that makes you feel comfortable/productive/happy. You are doing a lot of free work for me to easily consume even more of your free work and I do not take the efforts of packaging and polishing lightly. Thanks for everything!

[alphapapa]

Me reporting an issue/bug is not me prioritizing it for you to fix, I know I don't have that right :)

I know you didn't mean it that way. Sorry if I sounded harsh. My frustration isn't with you but with MELPA Stable, in general. It was a nice idea, but it just doesn't work out well in practice, and I think users should be discouraged from using it. It seems to cause more problems than it solves.

I also keep my entire config in git as well. I use stable to not avoid package churn, but to avoid behavior churn.

That's what I meant by "package churn." I like my Emacs config to just keep working the way I expect it to, so that's why I don't update packages very often.

My point is that MELPA Stable isn't necessary, or even necessarily helpful, for accomplishing that goal. What matters is 1) not updating packages until you're ready, and 2) being able to roll back to a known set of package versions.

IMO, using MELPA Stable is more likely to cause problems, because Emacs package authors don't give it much thought. So problems like the one we're discussing here are much more likely to occur when using only MELPA Stable.

For example, in this case, if you were using regular MELPA, you could simply update org-ql and org-sidebar, fix this problem, and leave all your other packages at their current versions. This function makes it easy to upgrade one package at a time (as well as this function if you use Quelpa).

That's all irrelevant though - please just stay publishing packages the way that makes you feel comfortable/productive/happy. You are doing a lot of free work for me to easily consume even more of your free work and I do not take the efforts of packaging and polishing lightly. Thanks for everything!

Thanks for the kind words. I do appreciate your feedback.