5 ms·

Haskell Platform is the last thing you should take inspiration from. Many of us have been doing our best to kill it off. Maybe the downsides involved wouldn't a

Haskell Platform is the last thing you should take inspiration from. Many of us have been doing our best to kill it off. Maybe the downsides involved wouldn't affect Rust in the same ways. My suggestion, look at how Stack (the tool) and Stackage (the platform) work: https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/ https://github.com/commercialhaskell/stack https://github.com/commercialhaskell/stack https://www.stackage.org/ https://www.stackage.org/

dikaiosune 10y ago
For those of us unfamiliar with Haskell, could you expand on the downsides a bit?
- coolsunglasses 10y ago
  This is the main thing I've written publicly on it: https://mail.haskell.org/pipermail/haskell-community/2015-September/000014.html https://mail.haskell.org/pipermail/haskell-community/2015-Se... My email is what finally moved the committee and GHC devs on including Stack with the Platform and on some other decisions concerning the website. Like I said, not all the downsides may be applicable to how Cargo works or what aturon has in mind, but please don't cite it as an exemplar of anything.
  - dikaiosune 10y ago
    That's quite the email! Without a TLDR, I'm not sure how to assess how susceptible Cargo is to those problems. My personal experience with Rust has been that there are very few instances where versioning or dependency issues cause me problems. The specific instances I have dealt with would be resolved by the proposal in the blog post (trying to use a version of serde which differs from what another core-ish library wants to use, etc.).
    - Ericson2314 10y ago
      IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason. On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination. I think most of this lesson doesn't apply to rust, but still good to be aware. It certainly gave me a strong eversion to course-grained dependency management as a bandaid.
      - coolsunglasses 10y ago
        >so many things Haskell are hard to build/install for no-good reason. Were. Were hard. It's quite fine now with Stack. I know users of all kinds of languages that all miss Stack when they're working on their non-Haskell projects.
        seagreen 10y ago
        Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite. EDIT: To elaborate on why I like Stack: + Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment can always be easily examined, committed to Git, etc. + Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing. + I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times. + It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.
        saysjonathan 10y ago
steveklabnik 10y ago
I actually cross-posted this to /r/haskell to get explicit feedback. Someone else mentioned stack/stackage. In my understanding, Cargo already does this specific behavior. Can anyone who's more familiar with both confirm this?
- coolsunglasses 10y ago
  I checked that other thread, I agree completely with jeremyjh's summary. The problem with Haskell Platform came down to a set of intersecting issues: - A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken) - Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period. You had to figure out the problem and fix it yourself if there was a truly irreconcilable issue. - Recommended installer on the website (Platform) was unnecessarily installing packages into the global package database, making you "stuck" with those versions for _all_ packages you attempted to build. Cabal was restricted to finding builds that abide by dependency versions narrowed to the ones provided by the global package database. These problems led to beginners being confused by seemingly spurious build failures because Platform would fall out of date with the rest of the ecosystem. Cabal would be unable to find sets of compatible dependencies and say it couldn't build the package. What non-beginners were doing to avoid these problems was: 1. Install the bare compiler, no Platform 2. Use package database sandboxes for each project All of these (UX and technical) problems were solved without compromising dependency conflict enforcement via Stackage and Stack. Speaking hypothetically, if Cargo behaves like Maven or Ivy and pulls in two dependencies who want conflicting versions (1.1 and 1.2, say) of a particular library and just picks a winner, then you'll never see something like this.
  - steveklabnik 10y ago
    Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.
    - coolsunglasses 10y ago
saysjonathan 10y ago
Most of your arguments linked in a comment below are unrelated to the application of metapackages to cargo. Cargo already includes a good portion of the behaviors found in Stack and Stackage. The idealogical battle of Stack vs Haskell Platform is irrelevant to this proposal. Haskell Platform is a perfectly adequate example to take high-level inspiration for the core of this idea: use Cargo (which is like Stack/Stackage for rust) to help bootstrap Rust libraries when using rustup to install and upgrade (mostly equivalent to `stack setup`).
Ericson2314 10y ago
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.
- burntsushi 10y ago
  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.
  - Ericson2314 10y ago
    Nah that's different. This is about avoiding unused dependencies, especially when they constrain portability.
- quodlibetor 10y ago
  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.
  - Ericson2314 10y ago
    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.

dikaiosune 10y ago

For those of us unfamiliar with Haskell, could you expand on the downsides a bit?

coolsunglasses 10y ago
This is the main thing I've written publicly on it: https://mail.haskell.org/pipermail/haskell-community/2015-September/000014.html https://mail.haskell.org/pipermail/haskell-community/2015-Se... My email is what finally moved the committee and GHC devs on including Stack with the Platform and on some other decisions concerning the website. Like I said, not all the downsides may be applicable to how Cargo works or what aturon has in mind, but please don't cite it as an exemplar of anything.
- dikaiosune 10y ago
  That's quite the email! Without a TLDR, I'm not sure how to assess how susceptible Cargo is to those problems. My personal experience with Rust has been that there are very few instances where versioning or dependency issues cause me problems. The specific instances I have dealt with would be resolved by the proposal in the blog post (trying to use a version of serde which differs from what another core-ish library wants to use, etc.).
  - Ericson2314 10y ago
    IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason. On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination. I think most of this lesson doesn't apply to rust, but still good to be aware. It certainly gave me a strong eversion to course-grained dependency management as a bandaid.
    - coolsunglasses 10y ago
      >so many things Haskell are hard to build/install for no-good reason. Were. Were hard. It's quite fine now with Stack. I know users of all kinds of languages that all miss Stack when they're working on their non-Haskell projects.
      - seagreen 10y ago
        Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite. EDIT: To elaborate on why I like Stack: + Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment can always be easily examined, committed to Git, etc. + Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing. + I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times. + It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.
        saysjonathan 10y ago

steveklabnik 10y ago

I actually cross-posted this to /r/haskell to get explicit feedback. Someone else mentioned stack/stackage. In my understanding, Cargo already does this specific behavior. Can anyone who's more familiar with both confirm this?

coolsunglasses 10y ago
I checked that other thread, I agree completely with jeremyjh's summary. The problem with Haskell Platform came down to a set of intersecting issues: - A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken) - Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period. You had to figure out the problem and fix it yourself if there was a truly irreconcilable issue. - Recommended installer on the website (Platform) was unnecessarily installing packages into the global package database, making you "stuck" with those versions for _all_ packages you attempted to build. Cabal was restricted to finding builds that abide by dependency versions narrowed to the ones provided by the global package database. These problems led to beginners being confused by seemingly spurious build failures because Platform would fall out of date with the rest of the ecosystem. Cabal would be unable to find sets of compatible dependencies and say it couldn't build the package. What non-beginners were doing to avoid these problems was: 1. Install the bare compiler, no Platform 2. Use package database sandboxes for each project All of these (UX and technical) problems were solved without compromising dependency conflict enforcement via Stackage and Stack. Speaking hypothetically, if Cargo behaves like Maven or Ivy and pulls in two dependencies who want conflicting versions (1.1 and 1.2, say) of a particular library and just picks a winner, then you'll never see something like this.
- steveklabnik 10y ago
  Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.
  - coolsunglasses 10y ago

saysjonathan 10y ago

Most of your arguments linked in a comment below are unrelated to the application of metapackages to cargo. Cargo already includes a good portion of the behaviors found in Stack and Stackage. The idealogical battle of Stack vs Haskell Platform is irrelevant to this proposal. Haskell Platform is a perfectly adequate example to take high-level inspiration for the core of this idea: use Cargo (which is like Stack/Stackage for rust) to help bootstrap Rust libraries when using rustup to install and upgrade (mostly equivalent to `stack setup`).

Ericson2314 10y ago

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.

burntsushi 10y ago
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.
- Ericson2314 10y ago
  Nah that's different. This is about avoiding unused dependencies, especially when they constrain portability.
quodlibetor 10y ago
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.
- Ericson2314 10y ago
  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.