Add command to export deps/config

[Papipo]

While implementing Gleam support in Elixir Mix, they asked me to avoid Regexes to parse the TOML config.

So hereby I request a new comand to export package deps in either JSON or erlang terms format (ie. gleam deps export).

I am not 100% sure if we'll need anything else from the config file, so exporting the whole thing (and not just the deps) might be desirable.

[lpil]

Super exciting!

I think you'd also need the name of the OTP application and whether there's an Erlang start module defined. Perhaps we expose the whole thing?

[Papipo]

I think you'd also need the name of the OTP application and whether there's an Erlang start module defined. Perhaps we expose the whole thing?

Yeah, better safe than sorry 😅

[lpil]

Is there any other information we might want to include? The Gleam version perhaps?

[giacomocavalieri]

So what should be exported as json, the content of the gleam.toml, manifest.toml or something else entirely?

[lpil]

It could not be the manifest as that would require dependency resolution, which must not be done outside a Gleam managed project.

Everything in the gleam.toml seems sensible, and we want to think if there's anything else that would be beneficial.

[Papipo]

Is there any other information we might want to include? The Gleam version perhaps?

Yes, I can add a check for that in the Mix integration. I'll need to check the gleam version anyway because this integration will be compatible with mix from the version this very issue is resolved and released.

[Papipo]

It could not be the manifest as that would require dependency resolution, which must not be done outside a Gleam managed project.

Right, Mix should take care of that.

Everything in the gleam.toml seems sensible, and we want to think if there's anything else that would be beneficial.

I think that once you start exporting some of the gleam.toml file, it's barely any work to export it all.

I was wondering, how would can we deal with javascript dependencies? I was assuming we would only support erlang ones, but what if someone wants to use a frontend package in Phoenix for example 🤔

I might need to discuss this with the Elixir people, and a first version of the integration might only support erlang libs.

[Papipo]

We are going to support a gleam_targets option in mix deps, so I also need the target config, if any. I think that just exporting everything is the best bet.

[lpil]

I was wondering, how would can we deal with javascript dependencies? I was assuming we would only support erlang ones, but what if someone wants to use a frontend package in Phoenix for example 🤔

You would manage them externally to your Mix project, the same as you would for Deno ones or npm ones or Elm ones, etc.

I might need to discuss this with the Elixir people, and a first version of the integration might only support erlang libs.

I don't think Mix should support anything except building for Erlang.

We are going to elixir-lang/elixir#14262 (comment), so I also need the target config, if any. I think that just exporting everything is the best bet.

That's not what that field means! I've commented in the PR.

[Papipo]

That's not what that field means! I've commented in the PR.

Thanks for the clarification. I was mistaken about that flag.

[Papipo]

I want to get the ball rolling. I think we need for sure:

• package name
• package version
• required gleam version
• [erlang]: application_start_module and extra_applications [1]
• dependencies

I don't think we need anything related to docs, js or dev-dependencies. The latter specially since we don't want transient dependencies, right?

[1] For these I would like to do some testing with an existing package. If you can point me to an existing package that uses those I'll be grateful

[lpil]

Design comes before implementation. We will not be changing project policy.

You could implement it on a fork for your own use if you want.

[Papipo]

Working on it.

I was thinking to either have a export mix-config that outputs something tailored for mix integration, or export package-config which pours the whole toml as JSON. Thoughts?

Maybe the latter could be also useful in the future in different contexts. But then I think I have to add Serialize stuff all over the place, right? So a specific MixConfig struct also would make sense.

What doesn't make sense is to have a generic command exporting a partial config, IMO.

Edit: Disregard that last comment, as that's what I actually did 😂