Scala layer: ensime needs to be pinned to stable.melpa.org

[what-the-functor]

Ensime reached a milestone 1.0.0 release; and now releases are being tracked on stable.melpa.org, whereas melpa.org tracks the development versions which are quite volatile.

Currently, we don't have an entry in 'package-archives for stable.melpa.org.
Locally, I've tried adding a melpa-stable entry, and pinning ensime in (use-package), however it still downloads from melpa.org (not stable.melpa.org). It's possible that I didn't use ':pin' correctly, or there could be a bug related to ':pin' (possibly upstream).

[bmag]

I believe Spacemacs installs a package if it is listed in a layer's packages and has a <layer>/<package>-init function. Installation isn't done through use-package, so pinning this way doesn't have an effect.

I don't think we have a canonical way of dealing with MELPA-stable packages. One way to handle it is to use a location recipe to install the correct version (via Quelpa). However, if a package in MELPA-stable depends on other packages in MELPA-stable, I don't know what versions of the dependencies will be used.

I wonder if anyone around here has a good idea of how to deal with MELPA-stable packages. Have you tried anything else? Maybe using package-pinned-packages?

[TheBB]

There's no way to do this yet. Spacemacs tracks volatile versions of all packages, ensime included.

See #2057 for more information. I'll close this as a duplicate. (Unless there are specific bugs in the unstable version, this is not currently a problem per se.)

[what-the-functor]

Hey @TheBB the thing is that melpa tracks the SNAPSHOT version of ensime. That means it's the development version, and by definition quite buggy at times. I appreciate your vigilance to close duplicates, but this one should be considered a bug. It's a bug due to changes outside of Spacemacs, but it essentially breaks the best functionality of the Scala layer. Please reopen.

[TheBB]

I respectfully disagree. Everything on melpa unstable is buggy at times, not because it's full of in-development versions of things, but because it is unstable. If ensime decides to use melpa unstable to distribute known buggy software, then they are in the wrong. If they just accidentally screw up sometimes, the situation is no different from all the other packages we're using. Some packages screw up more often than others, but we haven't made any exceptions so far (and in my experience, ensime has not been one of those).

I've yet to see any recent bug reports concerning ensime, which leads me to believe that there are currently no specific problems. When they do happen, they will be considered as bugs.

In summary it doesn't appear to me that there's anything particularly exceptional about ensime that warrants handling that package differently than the others, and so in my opinion this falls under #2057.

[syl20bnr]

Anybody tried to replace MELPA repo by MELPA stable? If this is a viable solution we could as a first step switch it to stable by default and provide an option to globally use non stable version.

My gut feeling is that in the end MELPA stable suffers the same issues as non stable with roughly the same probability of broken things, but the velocity is different (which is a trivial statement actually :-)) and the ecosystem more complicated (I doubt that MELPA stable can live on its own since a lot of packages may be missing and be available only on non stable. On the opposite non stable is self contained).

So to be more precise I'm ready for the move to MELPA stable if it can live on its own (we enable exclusively stable or non stable).

[syl20bnr]

Also if we use stable we must be prepared to do the police for untagged repositories. Maybe it is a good thing for the whole Emacs community. Some thought for the brain :-)

[TheBB]

If we switch to MELPA stable, we run into the problem that a lot of packages do not have stable versions. If we use both stable and unstable, all the packages will be installed from unstable anyway because of the versioning scheme (see melpa/melpa#2944 and melpa/melpa#2955), which brings us back to version pinning, which, granted, with quelpa is technically possible but very cumbersome on a large scale.

[what-the-functor]

The temporary fix, add the following to dotspacemacs/user-init in your .spacemacs file:

(push '("melpa-stable" . "stable.melpa.org/packages/") configuration-layer--elpa-archives)
(push '(ensime . "melpa-stable") package-pinned-packages)

Example:

(defun dotspacemacs/user-init ()
  "Initialization function for user code.
It is called immediately after `dotspacemacs/init', before layer configuration
executes.
 This function is mostly useful for variables that need to be set
before packages are loaded. If you are unsure, you should try in setting them in
`dotspacemacs/user-config' first."
  (push '("melpa-stable" . "stable.melpa.org/packages/") configuration-layer--elpa-archives)
  (push '(ensime . "melpa-stable") package-pinned-packages))

[WarFox]

Thank you @tonylotts, that worked for me 👍

[d12frosted]

@tonylotts Thanks for that workaround. I fetched more general solution in #6575.

[lizaveta-k]

Thanks @tonylotts !

[emanresusername]

note was just added to official ensime documentation

[strobe]

it looks like the approach from 6531 comment and ensime docs doesn't work anymore at least in my case.
How can I make a reproducible example for this? - do I need just clear packages and start from clear .spacemacs config or something else?

[d1egoaz]

It still works for me @strobe
What error are you getting?
How have you configured ensime-sbt?

[strobe]

with my config usually, I got a message that I'm using dev version of ensime with stable ensime-sbt. I had clear my packages and removed .spacemacs and after I started from scratch and found that in this case, I don't get that message. But anyway with both cases spacemacs has downloaded ensime-20170924.944 to elpa folder, but stable version at melpa is a 2.0.1 https://stable.melpa.org/#/ensime.

My ensime-sbt configs with clear version of spacemacs here https://gist.github.com/strobe/cb7c57a24461c737e15d1e153d4b609b (but even if global.sbt will be empty ensime-sbt will use lates stable version)

[jarutis]

I get the same behaviour as @strobe . Pinning does not seem to work anymore.

[diego-alvarez-hs]

sorry @strobe I was confused, I'm using the unstable version not the stable one, and as you mentioned, unstable is ensime-20170924.944j

[jdnavarro]

A workaround that worked for me was to download manually ensime-2.0.1 from melpa and add ensime to the dotspacemacs-frozen-list.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!