Earlier quoted context omitted.
I think it goes without saying that those with that sort of response tend not to use Windows, and also often seem to assume that a perfectly in-order Linux/Unix install is the only way to build software.
And also that you're fine with creating a package for any dependency that doesn't have one.
Cargo: predictable dependency management
51–60 of 146 posts
Re: Cargo: predictable dependency management
#52Something that I'm surprised this page doesn't talk about, and which is very important considering the recent hubbub over left-pad, is that any dependency you get on Cargo can be relied upon to continue to exist forever (well, as long as the crates.io site still exists, but if that goes away so does the Cargo index). The reason is because you can't ever remove a published version of your crate from crates.io. You can…
Maybe the reason why it's hardly talked about is because it's common sense and pretty much all dependency managers support it?
Except node of course, because they have no idea what they're doing.
Re: Cargo: predictable dependency management
#53Earlier quoted context omitted.
Happier than Rust 1.0 and the end of The Rustup?
End of The Rustup? AFAICS, it's still downloading a very specific servo-only rustc.
Re: Cargo: predictable dependency management
#54Cargo assumes you want to cache downloaded/built dependencies at the granularity of a unix user account. It's very easy to break things if you try to force current cargo cache dependencies at the per-project level and there's been no interest in caching things at a per-machine or shared-between-machines level. If duplicating compilation work is desirable to ensure some amount of noninterference, it should be supporte…
> it should put things in $XDG_CONFIG_HOME and $XDG_CACHE_HOME My unix does not follow XDG[0], neither of these are set and the XDG "fallbacks" are utter garbage, now what? [0] hell, only a minority of linux distros do at all
Re: Cargo: predictable dependency management
#55Earlier quoted context omitted.
It attempts to unify them if it can, but if they cannot be unified, it will include both versions.
Include both how? Make renamed copies to have two and modify the code to use the new names?
Re: Cargo: predictable dependency management
#56Earlier quoted context omitted.
End of The Rustup? AFAICS, it's still downloading a very specific servo-only rustc.
Servo's efforts to upgrade their version of rustc used to be legendarily traumatic, these days it's comparatively tame. :)
Re: Cargo: predictable dependency management
#57Earlier quoted context omitted.
Happier than Rust 1.0 and the end of The Rustup?
End of The Rustup? AFAICS, it's still downloading a very specific servo-only rustc.
Re: Cargo: predictable dependency management
#58How does Cargo handle indirect dependency visibility? This article talks about visibility in terms of "do I need to manually include indirect dependencies? No!" but not in terms of "can I accidentally write code against an indirect dependency?" which isn't sufficiently answered. If the answer is that indirect dependencies are still visible, I'd be interested in knowing if rust-lang/cargo plan to change that, similar…
Re: Cargo: predictable dependency management
#59Earlier quoted context omitted.
> You can yank a version, which tells Cargo not to allow any projects to form new dependencies on that version, but the version isn't actually deleted That's how RubyGems used to work, except you could contact the support team and ask them to permanently delete your gem version if something really sensitive and irrevocable was put into it. They had to change that due to their support log getting too big: http://blog.…
Cargo's policy is that if you upload secrets, you need to change the secrets because the code can't be deleted. From the aforelinked page: > A yank does not delete any code. This feature is not intended for deleting accidentally uploaded secrets, for example. If that happens, you must reset those secrets immediately.
Re: Cargo: predictable dependency management
#60Earlier quoted context omitted.
Cargo's policy is that if you upload secrets, you need to change the secrets because the code can't be deleted. From the aforelinked page: > A yank does not delete any code. This feature is not intended for deleting accidentally uploaded secrets, for example. If that happens, you must reset those secrets immediately.
Even if they're given a court order to take a version down? It may be their policy, but I guarantee it will happen at some point.