Use Gleam version as a constraint in package resolution

[mine-tech-oficial]

As the title describes, allow package resolution to consider the gleam field in gleam.toml as a constraint check, so that when packages upgrade to a newer Gleam version, users of it aren't required to manually adjust its range

[giacomocavalieri]

Would this be a net positive? Wouldn't we want to encourage folks to always keep their gleam version up to date?

[mtlynch]

This just bit me as well. I'm on NixOS, where the latest version of Gleam available is Gleam 1.10.0 even though the latest version is Gleam 1.11.0.

If I create a new project with gleam new, it pulls in a version of gleeunit that's incompatible with my version of Gleam:

$ gleam --version
gleam 1.10.0

$ gleam new --name myproject --skip-github .
Your Gleam project myproject has been successfully created.
The project can be compiled and tested by running these commands:

        gleam test
$ gleam run
  Resolving versions
Downloading packages
 Downloaded 2 packages in 0.01s
  Compiling gleam_stdlib
error: Incompatible Gleam version

The package `gleeunit` requires a Gleam version satisfying 1.11.0 <= v but you are using v1.10.0.

gleeunit 1.4.0 is correctly declaring its dependency on Gleam 1.11.0, so it would be helpful if gleam new considered that when choosing which version of gleeunit to pull in for a new project.

[manveru]

I was bit by the same issue, luckily NixOS/nixpkgs#407394 bumped Gleam to 1.11.0, but I think generally we should make use of the information that package maintainers provide to resolve versions properly.