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