Fix gleam run -m <module> behaviour with OTP entrypoint #5182
Conversation
Running a single module should call <module>:main/0 directly. Added unit tests for the same.
Prevents test helper methods from tripping 'unused function' check
J0s3c4rl0s
force-pushed
the
run-mod-interferes-start-mod
branch
from
f485343 to
5d8e907
Compare
|
Oops I accidentally included the build files in one of the commits.... 🤦🏼 I'll make sure to remove them and probably add a .gitignore file |
J0s3c4rl0s
force-pushed
the
run-mod-interferes-start-mod
branch
from
5d8e907 to
19d69b0
Compare
lpil
left a comment
lpil
left a comment
There was a problem hiding this comment.
Thank you! I've left a handful of comments inline. 🙏
| format!("{package}@@main:run({module})") | ||
| } else { | ||
| format!("{module}:main(), init:stop()") | ||
| }; |
There was a problem hiding this comment.
The entrypoint must always be used! Otherwise the virtual machine does not get booted correctly and the IO systems are not configured as Gleam code expects. Running it like this will cause many or most projects to fail when run.
There was a problem hiding this comment.
Does it?
I thought the whole point was that if we run a module outside of the current package we arent supposed to go through the entrypoint since this causes the bug?
Or is this moreso that if we happen to run a module within this package then it will try to run a module before the VM has been booted (and thus fail)?
Does this relate to the comments you made in the issue?
There was a problem hiding this comment.
No, the entrypoint must be run otherwise the application does not get booted.
The entrypoint need to be made to boot the correct OTP application for the module being run #4771 (comment)
There was a problem hiding this comment.
Okay so if I have main package A and dependency B if I run gleam run -m B.module then the CLI should boot the application B (with its entrypoint) rather than the application A (with its entrypoint), right?
P.S. Do you have any projects that will fail with this setting so I could use them as an example to compare/experiment with?
There was a problem hiding this comment.
That's right!
P.S. Do you have any projects that will fail with this setting so I could use them as an example to compare/experiment with?
If you make a project and define an application start module for it then it will fail when the dependency is run.
For the case where the dependency has a start module you can make it start a named process and have the function run by gleam run -m assert that it is alive.
test/OTP_run_module/gleam.toml
Outdated
| gleam_erlang = ">= 0.2.0 and < 2.0.0" | ||
| other_mod = {path = "../OTP_run_module_dep"} | ||
| gleam_otp = ">= 1.2.0 and < 2.0.0" | ||
| mist = ">= 5.0.3 and < 6.0.0" |
There was a problem hiding this comment.
These deps seem to be unused. Please remove all unused deps as they greatly increase how long this test takes to run.
|
|
||
| pub fn main() { | ||
| io.println("Hello from other_mod!") | ||
| } |
There was a problem hiding this comment.
gleam.toml says there is an application start callback in this module, but none has been defined. The test should fail because of this, but the implementation at the moment doesn't boot the project correctly, so it is never caught.
There was a problem hiding this comment.
I assume this should also be a problem in the base module OTP_run_module since it also has the application_start_module set?
Ill add some boilerplate for this, I used to have it and removed it since it didnt trip up any bugs.
3 participants
Closes #4771
This is a refactor of the solution in #4787 to satisfy the CI as well as adding an integration test on top of the unit tests.
The added test is:
test/OTP_run_moduleandtest/OTP_run_module_depBase project has an OTP entrypoint and runs module from dependency
cargo run run -m other_mod. This throws an error with the standard implementation but not with the bugfix.