So both versions of log crate manage their own internal states within the same process? Would this lead to surprising results?
Can a Rust binary use incompatible versions of the same library?
11–20 of 89 posts
Re: Can a Rust binary use incompatible versions of the same library?
#12Earlier quoted context omitted.
> (The more I work in Python, the more I think that Python's approach is actually a good one ...) I've come to the opposite conclusion. I've "git cloned" several programs in both python and ruby (which has the same behaviour) only to discover that I can't actually install the project's dependencies. The larger your gemfile / requirements.txt is, the more likely this is to happen. All it takes is a couple packages in…
I'm not saying this hasn't happened to you, but I'm curious: are you working with scientific Python codebases or similar? I've done Python development off and on for the last ~10 years, and I think I can count the number of times I've had transitive conflicts on a single hand. But I almost never touch scientific/statistical/etc. Python codebases, so I'm curious is this is a discipline/practice concern in different su…
I've had similar problems with python packaging in both the web dev and embedded spaces. There are ways to largely solve these issues (use package managers with lock files and do irregular dependency updates), but I rarely see that being done in projects I work in.
Re: Can a Rust binary use incompatible versions of the same library?
#13So both versions of log crate manage their own internal states within the same process? Would this lead to surprising results?
Their internal states in Rust are also namespaced, so two incompatible crates in the same process won't observe each others symbols. If they access external resources that are not namespaced though, that could be a problem.
Re: Can a Rust binary use incompatible versions of the same library?
#14Earlier quoted context omitted.
> (The more I work in Python, the more I think that Python's approach is actually a good one ...) I've come to the opposite conclusion. I've "git cloned" several programs in both python and ruby (which has the same behaviour) only to discover that I can't actually install the project's dependencies. The larger your gemfile / requirements.txt is, the more likely this is to happen. All it takes is a couple packages in…
I'm not saying this hasn't happened to you, but I'm curious: are you working with scientific Python codebases or similar? I've done Python development off and on for the last ~10 years, and I think I can count the number of times I've had transitive conflicts on a single hand. But I almost never touch scientific/statistical/etc. Python codebases, so I'm curious is this is a discipline/practice concern in different su…
If you use gRPC directly and some other library in your stack does it as well it's very likely you end up with conflicts either on gRPC itself or the proto library under the hood.
Re: Can a Rust binary use incompatible versions of the same library?
#15This is great for avoiding conflicts when you try to get your project running.
It sucks when there is a vulnerability in a particular library, and you're trying to track all of the ways in which that vulnerable code is being pulled into your project.
My preference is to force the conflict up front by saying that you can't import conflicting versions. This creates a constant stream of small problems, but avoids really big ones later. However I absolutely understand why a lot of people prefer it the other way around.
Re: Can a Rust binary use incompatible versions of the same library?
#16This is great for avoiding conflicts when you try to get your project running. It sucks when there is a vulnerability in a particular library, and you're trying to track all of the ways in which that vulnerable code is being pulled into your project. My preference is to force the conflict up front by saying that you can't import conflicting versions. This creates a constant stream of small problems, but avoids really…
Go got this right: you want an incompatible version, you have to use a different import path. Then you can only pick one version (which is deterministically the lowest possible version) for a certain import path, not a hundred different versions.
Also forces people to actually take backwards compatibility seriously.
Re: Can a Rust binary use incompatible versions of the same library?
#17This is great for avoiding conflicts when you try to get your project running. It sucks when there is a vulnerability in a particular library, and you're trying to track all of the ways in which that vulnerable code is being pulled into your project. My preference is to force the conflict up front by saying that you can't import conflicting versions. This creates a constant stream of small problems, but avoids really…
Go got this right: you want an incompatible version, you have to use a different import path. Then you can only pick one version (which is deterministically the lowest possible version) for a certain import path, not a hundred different versions. Also forces people to actually take backwards compatibility seriously.
I'm not surprised. Go's design is heavily informed by what does and does not cause cascading design problems in software engineering at scale. These practical concerns are very different from the kinds of issues that academia had been focused on. But practical solutions to practical problems is central to Go's popularity.
Re: Can a Rust binary use incompatible versions of the same library?
#18I cannot shake the feeling that this is actually a misfeature that will get people into trouble in new and puzzling ways. The isolated classloaders in Java and the assembly domains in .Net didn't turn out to be very bright ideas and from a software design perspective this is virtually identical.
Re: Can a Rust binary use incompatible versions of the same library?
#19So both versions of log crate manage their own internal states within the same process? Would this lead to surprising results?
Their internal states in Rust are also namespaced, so two incompatible crates in the same process won't observe each others symbols. If they access external resources that are not namespaced though, that could be a problem.
Such as stdout or stderr that a log crate would be using?
Re: Can a Rust binary use incompatible versions of the same library?
#20Earlier quoted context omitted.
There's a subtle point there though. When you rely on something that was introduced in x.y.z, stating that your version requirement is x.y.0 is an error that can easily cause downstream breakage.
I’m confused. If you rely on a feature introduced in X.y.z why would you specify X.y.0 to begin with (and not just X.y.z)? In practice, usual rust projects that have not put a ton of work into their dependencies encode X.y.z in Cargo.toml matching the current release at the time they developed the system. So you get at worst an unnecessarily higher version requirement but never a lower one. Moreover, rust semver woul…
It's easy to accidentally ship a minimum version requirement that is out of date when you also consistently use lock files pinned to newer versions. The code may silently depend on something introduced in a newer version pulled in by the lock file.