Pinned package dependencies

[bonega]

As far as I know Spacemacs always install bleeding edge packages from ELPA.

This leaves us with the fun situation where Spacemacs stability is a function of todays date.
E.g Spacemacs 0.102.2 will probably become more and more broken as packages change.

This is an unwanted behaviour for a supposed stable version(or any version).

Dependencies should be pinned to specific versions.
Also it is debatable if the bulk of packages should be installed from bleeding edge ELPA.
Rather something like melpa-stable(or elpa-stable if it exists).

The Clojure-repl integration Cider changes daily I think.
Since Elpa uses 0.9.1-SNAPSHOT.
A fair target would be 0.9.0 that was released as stable a few days ago.

I would think that a great deal of issues is dependent on the specific version of a package.
That makes it very hard to debug user problems in a safe way.

[dab]

👍 +1
packages versions should be hardcoded in releases

[codygman]

(thumbsup) Every once in a while I switch to spacemacs for a work week.
This would definitely help make that smoother.
On Jun 20, 2015 5:12 AM, "Dima Belitsky" notifications@github.com wrote:

[image: 👍] +1
packages versions should be hardcoded in releases

—
Reply to this email directly or view it on GitHub
#2057 (comment)
.

[sooheon]

This is coming to emacs itself in 25: http://endlessparentheses.com/new-in-emacs-25-1-archive-priorities-and-downgrading-packages.html

[syl20bnr]

I hear you.
We are not ready for such a move and the best is to stick with MELPA for everything for now. But rest assure that stable packages are planed:
1- merge extensions and packages into a single keyworded list
2- add support for Quelpa
3- from here we will be able to fetch the packages from source at a given commit which will give us full flexibility to tailor the spacemacs distribution.
4- I will be able to tag spacemacs 1.0 :-)

I will be able to work on the first step for 0.104.x

For the CIDER example, we have to move forward and use 0.9.1-SNAPSHOT like we used 0.9.0-SNAPSHOT before.

[bmag]

Hey, I just came across some short instructions on how to build a custom melpa archive. I'm not exactly sure what it entails, but I suspect that we could skip this step:

git rm recipes/*

Before a release we simply re-build all recipes with:

./melpa build

And use our own custom melpa archive (hosted on spacemacs.org?) instead of the bleeding-edge melpa.org archive.

[bmag]

Also for any extensions we need we could add a recipe in the recipes directory. I didn't try it or test it, but maybe it's worth a shot?

[bjeanes]

Since CIDER 0.10.0 was released on melpa, I've been having a really bad time getting CIDER and nrepl to work in Clojure. So, I'm recording my progress here for others who might experience a similar issue.

I added these lines to dotspacemacs/init function in .spacemacs:

(add-to-list 'package-archives '("melpa-stable" . "http://stable.melpa.org/packages/"))

(add-to-list 'package-pinned-packages '(cider . "melpa-stable") t)
(add-to-list 'package-pinned-packages '(clj-refactor . "melpa-stable") t)
(add-to-list 'package-pinned-packages '(cljr-helm . "melpa-stable") t)
(add-to-list 'package-pinned-packages '(ac-cider . "melpa-stable") t)

Then I rm -rf ~/.emacs.d/elpa/{cider,clj-refactor,clojure-mode}* and restarted Emacs. That got me back to CIDER 0.9 series. Hopefully that helps other people trying to pin to stable versions.

This requires Emacs 24.4 I believe...

[what-the-functor]

See #6531 for a example temporary fix.

[what-the-functor]

I've observed that if a melpa stable entry is added to configuration-layer--elpa-archives, everything works as normal (i.e. packages still resolve from melpa). Only those pinned to melpa-stable will resolve from melpa-stable. I propose building package-pinned-packages from an a-list in each packages.el. Packages that are not on melpa-stable will simply not be pinned. That will give us a path forward, without having to pin every single package in one go. When emacs 25 is more commonplace, and melpa versioning is ironed out, we can take advantage of package-archive-priorities.

[synic]

Is this moving anywhere? IMHO, this is one of the MOST important features. Spacemacs can NEVER be stable without it. Either bundling or pinning is necessary to guarantee that the features you're writing are against the same version of packages that your user will have installed. Anything else is just crazy.

At any time, any upstream package could change. This results in spacemacs master being different on the different machines you install it on, or the same machine if you re-install. You can't currently guarantee that evil won't release breaking changes and totally break spacemacs master.

[syl20bnr]

We started to bring more stability on the packages side with the elpa mirrors but there won't be pinned packages in the upcoming 0.200. This is something we can try to achieve for the next release. I think we have all the necessary tooling to do so, this is more a matter of hardware than anything else.

[d12frosted]

Yes, this is moving. Not as fast as some of us would want, but anyways.

I see two ways of solving this problem. First is to pin every package to specific version. Second way is to use package archive snapshot paired with specific version of Spacemacs. We are pretty close to using second solution as now we have our own elpa mirror, but let's see how it goes.

P. S. news.

[synic]

YAY!

This might be crazy, but I think it would be awesome if, once you get pinned packages, or bundle packages or something, there could be a long feature freeze time where all the kinks can get worked out. There are so many just little dinky bugs in various packages that could really just be resolved by folks using the same package version for a while (and obviously reporting bugs).

[syl20bnr]

Pinning is not really doable. First it implies that we have the pinned version somewhere, it won't be in MELPA since it tracks only the latest version. Second from a maintenance point of view it will be crazy to handle versions for each package.

The first point forces us to keep the package versions we pin somewhere so I see no advantage to pin packages. Since we have our snapshot better to use it as a whole for a given Spacemacs release. We will be able to update specific packages in a snapshot if required.

Users at any time will be able to subscribe to other snapshots, by default when installing Spacemacs the user subscribes to the snapshot of the installed release. Upgrading packages will be done against this snapshot. But later the user can subscribe to bleeding edge snapshot (ie MELPA under the hood) and get all the last versions of packages. This is all or nothing, I don't want to support pinning, you get what the currently subscribed snapshot gives to you. This simplify things a lot and we can better control consistency this way. In a sense it makes sense to couple configuration with a given version of a package while allowing opt-in for breeding edge at any time (but not intermediate versions).

To summary I propose the notion of snapshot which is a group of several elpa repos. Users can subscribe to snapshots. So we need a way to declare, list and subscribe to snapshots.

[syl20bnr]

We also need a storage backend for those snapshots, this is something we have to study.

[synic]

Snapshots sounds great. Don't really care about pinning, I mostly just care that you guys can predict what version of packages your users will have installed. If you cannot predict the version, you cannot predict the behavior :D

Really glad this is happening!

[skrat]

For anyone wanting to use @bjeanes workaround, put those lines into dotspacemacs/layers function.

[what-the-functor]

@skrat, the dotspacemacs/user-init function is the more cohesive place for that. Did that not work for you?

[skrat]

@tonylotts no it didn't

[agzam]

Can someone suggest a better solution here, @bjeanes workaround #2057 (comment)
fix broken CIDER for me, but it only worked when I have added those lines to dotspacemacs/layers
and that's ugly.
I thought I could use:

dotspacemacs-additional-packages '(
(cider :location (recipe :fetcher github
                          :repo "clojure-emacs/cider"
                          :commit "8a9eab32646abcaaf31fe83b2d897c01971b98f1"))

But that didn't work.

Maybe because all of them need overriding: cider clj-refactor cljr-helm ac-cider, I don't know, I don't have time to play with it.

[howdoicomputer]

A use-package bug was pushed and I think it broke fresh Spacemacs installs. Are snapshots going to be a thing?

EDIT: Wasn't a bug, per se... the package changed and the melpa recipe wasn't updated to reflect that.

[troglotit]

If someone like me faces this problem, I was advised to use this, it worked for me:

;; stable packages
  (add-to-list 'configuration-layer-elpa-archives '("melpa-stable" . "http://stable.melpa.org/packages/"))
  (add-to-list 'package-pinned-packages '(cider . "melpa-stable") t)

You have to put in dotspacemacs/init

[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!