Replies: 2 comments 2 replies
-
Yes, a PR is welcome! I think we can check against the current Elixir version using >= |
Beta Was this translation helpful? Give feedback.
2 replies
-
fixed with #1654 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The other day I ran into the situation that a remote node I wanted to attach to, didn't satisfy the elixir version. Since Livebook
0.8
the remote attached node should be at least1.14.2
, because there seems to be a dependency onCode.eval_quoted_with_env/4
, which was introduced in elixir1.14.2
.When connecting to a node with a lower version this results in an error raised
Code.eval_quoted_with_env/4 is undefined or private
.Would it be a good idea to check the remote node version when attaching? It seems like a good point to notify the user that things will go wrong (I don't think it's possible to run any code cell, with the example above). It might be even a good idea to prevent connecting at all.
I don't think the minimal attached node version is specified anywhere right now. The versions specified in mix.exs are used for compiling the Livebook version itself (
@elixir_requirement
) and copying the standalone runtime (@app_elixir_version
), but these versions could be different from what you expect from the attached node (at least, that's my understanding).I've made a simple playground prototype here (mostly for my own learning). If this is at all useful, I'd be glad to polish it up, or get feedback on what would be a good way to tackle this (for example, I have no idea what would be a good place to specify this version requirement, so it's hard-coded now, which obviously is not a good idea).
An example error message could be this:

Beta Was this translation helpful? Give feedback.
All reactions