> you fork it, make any modification you want, such as reducing the number of dependencies, but keeping it up to date with upstream is on you.
Say a pretty complex library has 30 dependencies. I fork it, I remove the dependencies, and now it doesn't build anymore. What do I do?
I feel like you're saying "You should not write the small feature you need yourself. Instead, you should heavily modify a big dependency that contains the feature you need, because that's certainly easier and better".
If the library did not rely on those 30 dependencies, it would not depend on them, would it?
> If you truly care about this, like the_mitsuhiko does, write it with no dependencies.
So you start by telling me that I should just remove the dependencies from my dependencies, and then you tell me that you don't do that and instead choose dependencies that don't have many dependencies themselves? It feels like we agree...
> not learning from history and reinventing wheel only square
This is the thing: "I learned from history so I don't reinvent the wheel" should not be treated like a religious belief. It's probably not a good idea to write your own kernel. But I often spend a day or two implementing a feature that I would have gotten from a dependency in 2h. And it's almost always worth it! And sometimes I depend on libraries (e.g. I usually don't rewrite an HTTP library).
> So you start by telling me that I should just remove the dependencies from my dependencies, and then you tell me that you don't do that and instead choose dependencies that don't have many dependencies themselves? It feels like we agree...
There are two cases:
1. You have 100 dependencies.
2. You just started writing your code.
If you are doing 1) then you have to vendor/fork till it's acceptable.
If you are starting from 2) just don't add them.
> This is the thing: "I learned from history so I don't reinvent the wheel" should not be treated like a religious belief.
Nothing in programming should be treated as religious belief. But duplicating code can be just as deadly as dependencies glut, taken to it's logical extreme.
A golden middle approach is best, sadly no one can agree on it.
> A golden middle approach is best, sadly no one can agree on it.
That's what I was saying: I think that we agree there. My initial point was that I don't think that the package management culture in Rust is a middle approach: it feels like most crates don't care about how many random dependencies they pull.
> My initial point was that I don't think that the package management culture in Rust is a middle approach
And I don't care about "cultures". They come and go, and change with time. What I care about are unchanging things - the programs.
Sane package managers allow you to make your code however you want to. OSS allows you to tweak the code in whatever way you need, arguing for CMake over npm is frankly baffling.
I was really talking about culture, which is important to me. The fact that many devs assume that everybody using Linux is on Ubuntu is culture, right? In Rust, it is often assumed that Rust was installed with rustup. It's nice to say "you are not forced to use rustup", but if it doesn't work when you don't, then you are kind of forced :-).
> Say a pretty complex library has 30 dependencies. I fork it, I remove the dependencies, and now it doesn't build anymore. What do I do?
If you don't know what to do in this situation it means you don't know how your dependency works, which means you've abdicated responsibility for your own code's runtime behavior. Please don't take this as accusatory, I do this almost every single day at work because it's unavoidable--I'd be fired if I didn't. But it makes me feel dirty.
The alternative is just as grim. I heard[1] that Excel went with the slogan "kill your dependencies" at least during Joel Spolsky's time. This ended with Excel team building and shipping their own C compiler.
Imagine NIH so hard, you start rewriting the compiler.
Say a pretty complex library has 30 dependencies. I fork it, I remove the dependencies, and now it doesn't build anymore. What do I do?
I feel like you're saying "You should not write the small feature you need yourself. Instead, you should heavily modify a big dependency that contains the feature you need, because that's certainly easier and better".
If the library did not rely on those 30 dependencies, it would not depend on them, would it?
> If you truly care about this, like the_mitsuhiko does, write it with no dependencies.
So you start by telling me that I should just remove the dependencies from my dependencies, and then you tell me that you don't do that and instead choose dependencies that don't have many dependencies themselves? It feels like we agree...
> not learning from history and reinventing wheel only square
This is the thing: "I learned from history so I don't reinvent the wheel" should not be treated like a religious belief. It's probably not a good idea to write your own kernel. But I often spend a day or two implementing a feature that I would have gotten from a dependency in 2h. And it's almost always worth it! And sometimes I depend on libraries (e.g. I usually don't rewrite an HTTP library).