-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Add gleam support to Mix #14262
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
base: main
Are you sure you want to change the base?
Add gleam support to Mix #14262
Conversation
421dc7c
to
0afa895
Compare
@josevalim when working on this I was always thinking of |
It should be possible because we use heroicons, a regular JS package, as a dependency on Phoenix applications. So we could probably support a |
Hello! You shouldn't need to do anything special target-wise as Gleam performs dead code elimination for code that is for other targets.
I would not expect Mix to become a front-end build tool by adding Gleam support. I think the workflow should be the same as it is today etc, with the desired build tool (esbuild, webpack, Adding frontend dependencies to the BEAM application dependency tree would either be wasted work compiling and managing them, or the programmer would need to go through every dependency in the lock file and add configuration to their
There is no such config. A Gleam package doesn't have an explicit target, each function in the public API is available on Erlang, JavaScript, or both, and they get either compiled or eliminated as needed. Whether a package is for Erlang or JavaScript is typically a matter of how the dependant is using them, not a matter of the configuration of the dependency. There is a |
b91ae71
to
c181ecd
Compare
@@ -269,6 +269,15 @@ Enum.each(fixtures, fn fixture -> | |||
File.cp_r!(source, dest) | |||
end) | |||
|
|||
## Set up Gleam fixtures | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And we should probably skip gleam tests if gleam is not installed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I guess I need to add gleam to CI (although I need to wait until my gleam PR is merged and released).
a18bf89
to
26c8aff
Compare
8a7d9fa
to
360db23
Compare
I am kind of copypasting this from the Gleam discord in case someone wants to try this out before merging into main: What is this?These changes add first-class support for Gleam in Elixir's Mix, thus allowing gleam path dependencies in What's missing?Probably nothing. Work on the gleam compiler is already merged and work on the Mix side is completed, but there might me rough edges, that's what we need to test. InstructionsMix integration will expect you to have gleam >= 1.10.0 installed and that hasn't been released yet. So:
If you were using UsageAfter running What needs to be tested?
ThanksJust report back with your findings and: thanks :person_bowing: Note: I hope these instructions are enough and correct. Let me know if that's not the case. |
@Papipo thanks for all the work so far! One question: I thought that |
No, gleam is a single binary written in Rust. I don't know if we can provide a hex archive maybe? I don't know how these work. How is rebar installation handled? I know that mix is able to install it locally, but I am not sure what that means exactly. It's still a binary as well, right? |
For Rebar, we have some binaries which we upload to hex.pm, and we version control them every year or so. Although I don't think this will work for Gleam, because people want to upgrade it more frequently, and Rebar is only a build tool, not really a compiler. So I guess we need to be clear we are using the system one and it is up to them to enforce the team uses the same version across the board (which is how we deal with |
In fact the binary is also the LS, so you definitely want to have full control of the version you are using, etc. |
Quoting @lpil on the forums:
Apologies but I am a bit confused. We are using The .app file has things like app name, version, description, registered processes, app environment, and module names. We would need to lift all of this information from the Gleam .toml and make assumptions on how Gleam wants those be used. Worst case scenario, couldn't Gleam support an |
Yes, From @lpil comment over elixirforum I assume the problem are colocated Elixir files within a Gleam project. The Gleam compiler knows nothing about them so any modules they define can't be written in the .app file, I guess. What I have done here is use the Mix task to generate the .app file (and inject the two options gleam.toml supports for the erlang target: Let me know if this looks good or if I should revert it. Thanks. |
Yes, for collocated projects that’s the responsibility of Mix, but for packages I would say that’s Gleam responsibility. Otherwise there is even more we need to understand from Gleam TOML’s and we may need to keep track of it as it evolves. So is there a chance for it to emit an .app file either by default or via a flag? On the plus side, if Rebar wants to integrate Gleam as well, they can reuse it to emit apps too. :) |
b70f8fd
to
b64f23a
Compare
Apparently this seems to be working fine except that people sometimes need to compile twice . Could this be code path related maybe? It's probably something stupid I missed. |
Oh! That's a good idea, much easier. I think I would prefer to not have Gleam generate the |
From what I've seen, we could dump the If gleam options there adhere to the expected format (which I hope is the same as Erlang's) we should be good with the former, no? |
Yes, exactly. |
If the root Mix project has a path dependency on a gleam dependency, where should I put this |
oh, that would be a problem with this approach. So maybe, instead of writing the file to disk, you should just push the project data, like we do on It does have one issue though, in that we would have no way to pass application properties (because there is no |
I still need to add support for that but the rest is already working. Can you please verify that how I am using I'll add support for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using ~w
and ~W
sigils is more idiomatic when passing command line args
@eksperimental I am somehow having trouble with spaces in paths when using the sigils:
It's splitting the string by spaces in the path. |
Good catch! |
This is a hybrid solution. No sure if the clearest, so it's your call whatever you think works best. ~w(compile-package --no-beam --target erlang --package #{package}) ++ ["--out", out, "--lib", lib] |
- Add Mix.Gleam module - Add specific gleam binary version requirement - Rely on `gleam export package-info`
- shell_cmd! wasn't handling tuples - Fix documentation
This is an optional value within [erlang] in the gleam.toml file. It will be used for the `mod` value when generating a .app file
Co-authored-by: Eksperimental <eksperimental@autistici.org>
9dde3f5
to
b75dc61
Compare
@josevalim that's implemented and everything seems to be working fine. I think I have a flaky spec in Apart from that, the only thing missing is adding gleam to CI if we don't want to skip those tests, which I assume is the case. |
Thank you. Yes, we should add Gleam to the CI. :) Keep in mind though I am going for holidays and then preparing for ElixirConf, so it may take a while before I get to fully review this. Apologies. |
No problem, enjoy your trips! |
This PR adds support for the gleam language.
gleam.toml
inpath
depsgleam
in deps loader.deps.compile
gleam
binary version (hardcoded to 1.9.0 for now, see below)gleam
binarymain
already but not yet released):application
option inMix.ProjectStack.push
(thus anapplication
function is not needed)Notes:
gleam
binary version requirements are handled automatically when executinggleam compile-package
.gleam export package-info
but I can't know the reason for a bad exit status (maybe the dep path was wrong and the command was run in a dir without agleam.toml
).is not yet released but has already been merged. Should land on v1.10.0.Was released on v1.10.0