5 ms·

I would like to contrast the underlying philosophy here to that of Go. As you may be aware, there is limited support for versioning APIs using "go get" (Go's n

by Jabbles 12y ago

I would like to contrast the underlying philosophy here to that of Go. As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions. If a project B depends on project A, then they must collaborate in some way to make sure that there are no breaking changes introduced between (minor) versions. If another project C also depends on A, then they must both use the same version of A if they are to be used together. The maintainers of A, B and C all have a duty to ensure that their code remains up-to-date and backwards compatible. It seems that Rust values a different freedom. By specifying the exact version you require, there is no need to keep separate projects in sync. The flexibility comes at a cost; you may find you have different versions of many dependencies. Because they are not required to, maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, requiring bugfixes in multiple places in your own codebase. Clearly, some of the smartest minds in our industry disagree what the best tradeoff is. It is interesting to see the range of opinion though.

steveklabnik 12y ago
Small nits about the way this works: > By specifying the exact version you require, This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like foo = "^1.2.0" and then, during the build step, it resolves all of the dependencies and their dependencies (etc) and writes the exact version out to a file. So you do end up with specific ones, but you won't neccesarily end up with multiple versions. This also matters because... > maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.
andrewchambers 12y ago
Go is always statically linked at the moment so it makes more sense in that scenario.
- pcwalton 12y ago
  I don't think that the linking semantics make much of a difference in what you should do with your source. Rust is, in fact, usually statically linked as well. Dynamically linked Rust crates are supported, but are uncommon in practice. (The most common use cases for dynamically linked Rust crates at the moment are compiler plugins and embedding Rust into other languages.)
  - andrewchambers 12y ago
    For a dynamic library you need to ensure your source will work with the version range the package manager allows to be installed. Which may or may not be the most up to date version. Subtle things in dynamic linking may break applications when dependency versions are changed. Static linking lets you bundle whatever version is known to work, including the most up to date versions.
demarq 12y ago
"The developers of Go argue that the maintenance of your dependencies is your responsibility" THIS! I should also state I fall on the extreme end of the spectrum. My belief is that the moment you depend on upstream package X it is wholly your responsibility to track changes and adapt your code accordingly. I don't believe software versioning does anything but encourage poor security, performance and general fragmentation. I believe that before pushing your changes to a remote repo, you locally check that everything is stable, meaning there is no dev branch or stable releases just one true master branch! If you don't want the bleeding edge then don't 'git pull'. simple!
- dbaupp 12y ago
  Cargo gives you exactly this, btw: if you don't want to change the version of upstream code on which you depend, don't run `cargo update`. (This applies to both git dependencies and registry dependencies.)
  - demarq 12y ago
    believe me I will 'cargo update' always! the problem is those who don't and still go on to publish libraries, what happens when he needs version 2.1 of X while another library needs version 3.4? And thus anyone who depends on these two libraries now ends up with duplicate libs. What if they also depend on other libs with the same problem... The world goes boom! exponential overload! ... at least it get's really frustrating after a while, twice the space, twice the compilation time. And you'll know at least one of the libs has bugs lurking in it that have been fixed elsewhere except in that lib:(
mercurial 12y ago
? As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions. That's the last time where I heard about this wonderful idea that vendoring everything is a solution, because versioning is hard: https://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre/posts/373466 https://www.kickstarter.com/projects/2066438441/haunts-the-m... I'll take the solution where I can send a PR to the maintainer with updated dependencies over this sort of thing any day.

by Jabbles 12y ago

steveklabnik 12y ago

Small nits about the way this works: > By specifying the exact version you require, This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like foo = "^1.2.0" and then, during the build step, it resolves all of the dependencies and their dependencies (etc) and writes the exact version out to a file. So you do end up with specific ones, but you won't neccesarily end up with multiple versions. This also matters because... > maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.

andrewchambers 12y ago

Go is always statically linked at the moment so it makes more sense in that scenario.

pcwalton 12y ago
I don't think that the linking semantics make much of a difference in what you should do with your source. Rust is, in fact, usually statically linked as well. Dynamically linked Rust crates are supported, but are uncommon in practice. (The most common use cases for dynamically linked Rust crates at the moment are compiler plugins and embedding Rust into other languages.)
- andrewchambers 12y ago
  For a dynamic library you need to ensure your source will work with the version range the package manager allows to be installed. Which may or may not be the most up to date version. Subtle things in dynamic linking may break applications when dependency versions are changed. Static linking lets you bundle whatever version is known to work, including the most up to date versions.

demarq 12y ago

"The developers of Go argue that the maintenance of your dependencies is your responsibility" THIS! I should also state I fall on the extreme end of the spectrum. My belief is that the moment you depend on upstream package X it is wholly your responsibility to track changes and adapt your code accordingly. I don't believe software versioning does anything but encourage poor security, performance and general fragmentation. I believe that before pushing your changes to a remote repo, you locally check that everything is stable, meaning there is no dev branch or stable releases just one true master branch! If you don't want the bleeding edge then don't 'git pull'. simple!

dbaupp 12y ago
Cargo gives you exactly this, btw: if you don't want to change the version of upstream code on which you depend, don't run `cargo update`. (This applies to both git dependencies and registry dependencies.)
- demarq 12y ago
  believe me I will 'cargo update' always! the problem is those who don't and still go on to publish libraries, what happens when he needs version 2.1 of X while another library needs version 3.4? And thus anyone who depends on these two libraries now ends up with duplicate libs. What if they also depend on other libs with the same problem... The world goes boom! exponential overload! ... at least it get's really frustrating after a while, twice the space, twice the compilation time. And you'll know at least one of the libs has bugs lurking in it that have been fixed elsewhere except in that lib:(

mercurial 12y ago

? As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions. That's the last time where I heard about this wonderful idea that vendoring everything is a solution, because versioning is hard: https://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre/posts/373466 https://www.kickstarter.com/projects/2066438441/haunts-the-m... I'll take the solution where I can send a PR to the maintainer with updated dependencies over this sort of thing any day.