Adds deps why functionality

[Ramkarthik]

Addresses #3267

gleam deps why gleam_stdlib

For ex: Running this on the test/project_erlang project returns the following output:

gleam_erlang 0.24.0
gleam_javascript 0.7.1
gleeunit 1.0.2

This is my first PR for this project. I appreciate any feedback to improve this.

[giacomocavalieri]

I think this is implementing something slightly different, what we want is given one of the package's direct dependencies a list of all the constraints introduced by the other packages that lead to picking a given version. For example:

gleam deps why gleam_json

gleam_json >= 2.0 and < 3.0

constraints from your dependencies:
wibble_package >= 1.0 and < 3.0
wobble_package >= 2.0 and < 3.0

But I might have interpreted the issue wrong, it's better to wait for Louis here :)

[Ramkarthik]

Ah, my bad. That makes sense. Once Louis confirms, I will close this PR and try implementing the behavior you mentioned.

[lpil]

That's right! The output should show all the ways that a package is added to the project.

Perhaps something along the lines of cargo tree or npm why

 $ cargo tree --invert cfg-if
cfg-if v1.0.0
├── crc32fast v1.4.0
│   └── flate2 v1.0.30
│       ├── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
│       └── hexpm v2.4.1
│           └── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
├── dirs-next v2.0.0
│   └── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
├── filetime v0.2.23
│   └── tar v0.4.40
│       └── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
├── getrandom v0.2.12
│   ├── rand_core v0.6.4
│   │   ├── im v15.1.0
│   │   │   └── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
│   │   ├── rand v0.8.5
│   │   │   [dev-dependencies]
│   │   │   └── gleam-core v1.3.2 (/Users/louis/src/gleam/gleam/compiler-core)
│   │   ├── rand_chacha v0.3.1
│   │   │   └── rand v0.8.5 (*)
│   │   └── rand_xoshiro v0.6.0
│   │       └── im v15.1.0 (*)
│   └── ring v0.17.8
│       └── hexpm v2.4.1 (*)
├── ring v0.17.8 (*)
└── tempfile v3.10.1
    ├── protobuf-codegen v3.4.0
    │   [build-dependencies]
    │   └── hexpm v2.4.1 (*)
    └── protobuf-parse v3.4.0
        └── protobuf-codegen v3.4.0 (*)

Showing the constraints would be fab here

[Ramkarthik]

Apologies. Thank you for details, @lpil. I will give this a try.

[lpil]

Maybe it could be a gleam deps list though? Would that be helpful? What do you both think @Ramkarthik @giacomocavalieri ?

[Ramkarthik]

@lpil Like gleam deps list packagename (optional packagename)? Would it list all the packages that depend on packagename (this PR) or would it list the dependencies of packagename (requirements) along with the version?

Regarding deps why, I've been trying a few things but I'm hitting some blocks, primarily because I'm new to both Gleam and this code base, so apologies for the very basic questions:

Both cargo and npm seem to be reading the dependencies from the cargo.lock and package-lock.json file respectively (if I'm not wrong). In the case of gleam case, the manifest.toml file has requirements for each package but doesn't have the version range. Is the right approach to first add the version range for each dependency/requirement to the manifest.toml file? Or should we be getting the dependencies from a different place?

[lpil]

Maybe just gleam deps list and it'll list all deps and their versions?

Both cargo and npm seem to be reading the dependencies from the cargo.lock and package-lock.json file respectively (if I'm not wrong). In the case of gleam case, the manifest.toml file has requirements for each package but doesn't have the version range.

No I don't think this information should be in the manifest. Neither npm or Cargo store this information in the lock either.

Perhaps just having the versions and not the constraints would be a good place to start

[Ramkarthik]

@lpil @giacomocavalieri I finally had some time to take another stab at this. I have an implementation that works like this:

1. gleam deps tree

deps_list v1.0.0
├── gleam_regexp v1.0.0
│   └── gleam_stdlib v0.52.0
├── gleam_stdlib v0.52.0
├── gleeunit v1.2.0
│   └── gleam_stdlib v0.52.0
└── pog v3.1.1
    ├── gleam_stdlib v0.52.0
    └── pgo v0.14.0
        ├── backoff v1.1.6
        ├── opentelemetry_api v1.4.0
        └── pg_types v0.4.0

2. gleam deps tree --package pog

pog v3.1.1
├── gleam_stdlib v0.52.0
└── pgo v0.14.0
    ├── backoff v1.1.6
    ├── opentelemetry_api v1.4.0
    └── pg_types v0.4.0

3. gleam deps tree --invert gleam_stdlib

gleam_stdlib v0.52.0
├── deps_list v1.0.0
├── gleam_regexp v1.0.0
│   └── deps_list v1.0.0
├── gleeunit v1.2.0
│   └── deps_list v1.0.0
└── pog v3.1.1
    └── deps_list v1.0.0

This is more inline with how Cargo works. Is this something we are still interested in? I wanted to check before I create a PR.

[lpil]

Looks great!!