Skip to content
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

Transitive Dependency Warnings via gleam compile-package #2566

Open
tynanbe opened this issue Jan 25, 2024 · 4 comments
Open

Transitive Dependency Warnings via gleam compile-package #2566

tynanbe opened this issue Jan 25, 2024 · 4 comments
Labels
bug Something isn't working good first issue Good for newcomers help wanted Contributions encouraged priority:low

Comments

@tynanbe
Copy link
Member

tynanbe commented Jan 25, 2024

As mentioned in gleam-lang/mix_gleam#38

The gleam compile-package API should perhaps not generate these warnings, or have a flag to disable them.

@tim2CF
Copy link

tim2CF commented Jan 29, 2024

Not sure what exactly happen, but this change did solve the transitive dependency issue at least in my project
gleam-lang/mix_gleam#39

@lpil lpil added bug Something isn't working help wanted Contributions encouraged good first issue Good for newcomers priority:low labels Jan 30, 2024
@brunoparga
Copy link

So, I have never written a line of Rust in my life, but I'm trying to follow what exactly causes this to happen, and think in general terms of a solution.

analyse::record_imported_items_for_use_detection emits the warning if !direct_dependencies.contains_key(&module_info.package) (and other conditions). I presume that if dependencies from mix.exs make their way into this direct_dependencies HashMap argument, the issue will be solved; I would like y'all's opinion on whether this is indeed the case and a desirable solution.

I tried to figure out how the dependencies from gleam.toml make their way to this direct_dependencies thingy. Here's the path of function calls I could identify:

  • analyse::record_imported_items_for_use_detection
  • analyse::infer_module
  • package_compiler::analyse (where dev dependencies are included if needed)
  • package_config.dependencies_for
  • package_compiler.compile
  • package_compiler.new (as that creates the config struct with the deps)

Here it branches into two paths, each reaching two very similar functions:

  • project_compiler.compile_gleam_package
  • project_compiler.compile_gleam_dep_package
  • package_config.read

-or-

  • compile_package::command
  • config::read

Both these read functions parse TOML. ProjectCompiler also has a compile_mix_dep_package method, which I don't know if it is related.

So, a few questions:
1 - should there really be these two almost identical read functions?
2 - how can they be modified to include dependencies from mix.exs so the transitive deps warning goes away?
3 - is this all anywhere near correct?

@lpil
Copy link
Member

lpil commented Mar 22, 2024

As Tynan says the solution is to have the gleam compile-package API not emit that warning ever, so it just needs to set some extra configuration on the package compiler which is passed to the analyser.

@brunoparga
Copy link

Yeah, that seems more complicated than I can do with zero Rust knowledge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Contributions encouraged priority:low
Projects
None yet
Development

No branches or pull requests

4 participants