#157 breaks the config for users who use versioned embark and embark-consult

[sthesing]

With the versions of embark and embark-consult that are available on elpa and melpa stable (0.16), the additions to rational-completion introduced by #157 leads to the following error when starting Emacs:

"Symbol's value as variable is void: embark-collect-initial-view-alist"

Reproduce:

• clone a fresh install of rational-emacs
• use a config.el that contains (require 'rational-completion)

Workaround

1. Pin embark and embark-consult (and it's probably a good idea to do the same with consult) to use the their latest versions in early-config.el:

(add-to-list 'package-pinned-packages '(consult . "melpa"))
(add-to-list 'package-pinned-packages '(embark . "melpa"))
(add-to-list 'package-pinned-packages '(embark-consult . "melpa"))

2. Hit "M-x" and run list-packages
3. When prompted about packages that can be updated, type "U" to mark the three packages for update and "x" to apply the updates.
4. Restart Emacs

[jeffbowman]

Hmm... I'm not seeing this. I'm using embark 0.16 and on line 2412 there is a defcustom definition for embark-collect-initial-view-alist. I followed your instructions to checkout a brand new rational-emacs and add a config.el with a (require 'rational-completion) and I don't see this error.

I have the following installed:

• embark-0.16
• embark-consult-0.5
• consult-0.17

[sthesing]

Hm... I do. Albeit not on the first startup. Did you launch the same Emacs environment a second time? If so, I'll have to go hunting for other factors that might be at play here...

[jeffbowman]

I launched it several times. I do notice that if I have one or two of the three from melpa and one from melpa-stable, I get the error you mention. In my case having all three from the same repo seems to help. Thus having all three from melpa-stable (the default) seems to work for me, just as having all three from melpa does (by pinning them). However, having consult and embark-consult from melpa and embark from melpa-stable seems to have the problem you mention here.

[sthesing]

Strange, my test config.el contains nothing but (require 'rational-completion). If that's also the case for your test environment, then it's puzzling that we get different results. Is there a possible element of random in the process that selects the respective repository if they contain the same version number of a given package?

Is there a way we could ensure an error free startup in the module? Otherwise, we should maybe add something about this in the README.

Come to think of it, maybe we should inform new users about possible issues with outdated packages and possible workarounds. Currently they have to find that info in closed issues. Still, I'm on my continuing mission to ensure an error free example config for new users ;-) So if anyone has an idea on how to make sure a fresh install of rational-emacs continues to start up without errors, that would be great. I'm at a loss, here.

[jeffbowman]

See the package-archive-priorities in the early-init.el file. That sets the preference on where to get packages. To summarize here, it will try in order "gnu", "nongnu", "stable" (aka melpa-stable), and finally "melpa". The first repo that provides a version of the package wins, which is why we get embark-consult-0.5, it is found in the "gnu" repo before the version in melpa-stable (which happens to be embark-consult-0.16).

So, that should manage the apparent randomness.

Yes, we should provide some troubleshooting tips in the readme. I've intended to do this, but have been busy with work so, I haven't gotten around to it yet. I'll get to it eventually or someone might submit a PR... (ahem... ;-))

[sthesing]

It shouldn't be a problem any longer in this concrete case, since Omar has (after a little nudging) initiated a version bump for Embark.

Still, the general phenomenon won't go away. We should inform users about pinning and ask contributors to test against a fresh install.

I'm currently far away from a proper internet access, but I'll draft something soon, unless someone else is quicker :-)

Closing this now.