tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier ([personal profile] tim) wrote 2013-10-04 04:49 am (UTC)

1. Making dependencies local to each package, which is what rustpkg does (not that this is original to rustpkg -- it's borrowed from Go) is meant to prevent getting stuck in dependency hell. Ideally, *all* of a package's dependencies would be stored in a subdirectory that's unique to the package itself (the .rust directory within the workspace that the package is in).

The ideal doesn't always work, which is why rustpkg supports the RUST_PATH, which I've talked about before -- it's a way to set a destination for installed packages so that those shared libraries can be shared by different packages. But someone who never customizes the RUST_PATH will find that the default behavior is the easiest one to work with. And yes, this does result (potentially, anyway) in multiple copies of the same version of the same library living on the disk, but we're betting on disk space being cheap enough that this doesn't matter. Of course, we'll have to see how it works out in practice.

2. I don't think this is much of an issue with rustpkg, as installation should be totally automatic.

3. With the default behavior that I described, old (unused) versions of packages could certainly sit around on the disk indefinitely. But with dependencies kept local, this doesn't cause any harm except for taking up disk space (and imaginably, rustpkg could have a "gc" command that would list the names of installed packages that have newer versions available, so you can easily see stuff you're not using).

I don't know if any of that was clear, since I'm jetlagged, so feel free to ask clarifying questions :-)

Post a comment in response:

This account has disabled anonymous posting.
(will be screened if not on Access List)
(will be screened if not on Access List)
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting