Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn if lein < 2.9.0 #2630

Open
dl1ely opened this issue May 1, 2019 · 7 comments
Open

Warn if lein < 2.9.0 #2630

dl1ely opened this issue May 1, 2019 · 7 comments

Comments

@dl1ely
Copy link

@dl1ely dl1ely commented May 1, 2019

Accidently, i tried using cider with lein 2.8.1 (default version when installed through apt on Linux Mint). Because of the group-id/artifact-id change of nrepl, the dependency injection on the lein command line for nrepl 0.6.0 does not work when doing cider-jack-in, because loading org.clojure/tools.nrepl seems to have precedence over nrepl/nrepl. Even adding the nrepl/nrepl dependency in ~/.lein/profiles.clj as described in the troubleshooting section does not help. The repl buffer is rightfully complaining that i should at least use nrepl 0.4.4, but the root cause (failed dependency injection because of outdated lein version) stays hidden, because the commandline displayed in the minibuffer when doing cider-jack-in clearly states the nrepl/nrepl 0.6.0 dependency.

After finding the root cause (and noticing the minimum lein version requirement in the cider documentation) and updating to lein 2.9.1 everything worked smooth.

It would be very helpful when the repl buffer would warn me about my outdated lein version instead of or additionally to the warning about the outdated nrepl version. I guess this could be done by calling lein version and parsing the output when the nrepl version is detected to be too old. Unfortunately i cannot provide a PR because i am lacking elisp knowledge.

@bbatsov
Copy link
Member

@bbatsov bbatsov commented May 1, 2019

You're making a good point, but running lein version is crazy slow, so we should do something else. I'm open to suggestions.

@timvisher
Copy link

@timvisher timvisher commented May 1, 2019

Don't know how much of a hack you'd think this would be but I checked every version since 2.5.3 (the version I'm stuck on) and they all have a well-formed export statement in the script. You could just check that. It's what controls which version of the jar is run.

vagrant@taps-tvisher1:~/git/leiningen$ while read -r tag; do curl -s -L https://github.com/technomancy/leiningen/raw/"$tag"/bin/lein | grep -F -- 'export LEIN_VERSION='; done < <(git tag --contains 2.5.3)
export LEIN_VERSION="2.5.3"
export LEIN_VERSION="2.6.0"
export LEIN_VERSION="2.6.1"
export LEIN_VERSION="2.7.0"
export LEIN_VERSION="2.7.1"
export LEIN_VERSION="2.8.0"
export LEIN_VERSION="2.8.0-RC1"
export LEIN_VERSION="2.8.1"
export LEIN_VERSION="2.8.2"
export LEIN_VERSION="2.8.3"
export LEIN_VERSION="2.9.0"
export LEIN_VERSION="2.9.1"
@dl1ely
Copy link
Author

@dl1ely dl1ely commented May 1, 2019

Not an expert on how lein works, but is this env variable available in the repl process and thus somehow visible to cider?

Other thought: Does the output of the lein repl call contain the lein version and could be parsed?

@timvisher
Copy link

@timvisher timvisher commented May 1, 2019

No it's not available outside the script. Cider would need to parse it out of the script by hand. At least AFAICT.

@dl1ely
Copy link
Author

@dl1ely dl1ely commented May 1, 2019

Given that lein version only needs to be executed when there is an "error-like" condition anyway (outdated nrepl), and not regularly, i am not sure the added time to execute that check really is a problem.

@bbatsov
Copy link
Member

@bbatsov bbatsov commented May 2, 2019

I brought this up because ideally we'd check for this before we actually start a server and get some weird results. After the server is running checking for the lein version is easy, but I don't think that's what we want to do in this scenario.

@dl1ely
Copy link
Author

@dl1ely dl1ely commented May 2, 2019

Well, i thought it would be handled like the warning about the outdated nrepl version. So still offer the (potentially limited) repl functionality, but improve the specificity of the warning to give a clearer hint how to fix the problem. If it should be checked beforehand efficiently, then i see no other way as to parse the shell script. But that gives me an uneasy feeling because of brittleness, and Windows needs to be considered, too…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.