Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

The one thing stack does do nicely that this proposal doesn't is allow curated comparable versions without forcing course dependencies. In plainer English, stack can pick the versions while you still opt in pack by package. I beleive that this is crucial to not slow down the evolution of the ecosystem.

In Cargo jargon, a solutuon would be for metapackages could double as sources: `foo = { metapackage = bar }` to use foo from bar.

View on HN

To make this more concrete, you're suggesting something like

   [dependencies]
   hyper = { metapackage = { rust-platform = "2.7" } }

I like the general theme of having the platform be just a set of known-compatible versions, but on the other hand this feels like it loses out on many of the ease-of-use advantages of just specifying a platform version and knowing that you have all the crates inside of it.

Yeah that's a proper example.

I don't think we need to pick one way exclusivity. My specific use-case is making PRs for packages to work in kernelspace / in unikernels. The library night initially be packaged the easy way but then I'd use this. I don't want the PR recipient to also worry they might get out of sync with the platform as a side effect.

If I'm understanding your concern correctly, that's totally a part of the proposal:

    But we can do even better. In practice, while code will continue working
    with an old metapackage version, people are going to want to upgrade.
    We can smooth that process by allowing metapackage dependencies to be
    overridden if they appear explicitly in the Cargo.toml file.

Nah that's different. This is about avoiding unused dependencies, especially when they constrain portability.

Reply on news.ycombinator.com