5 ms·

> Vendoring is not a solution, because it does not remove the transitive dependencies. So I have to essentially rewrite it myself. Vendoring means, you fork it

by Ygg2 2y ago

> Vendoring is not a solution, because it does not remove the transitive dependencies. So I have to essentially rewrite it myself. Vendoring means, 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. Rewriting it for yourself is what happens in C++. C++ didn't get flatter by waving a magic wand, it just moved the slider. It's just that code reuse is hard, so you rewrite things that would be a shared dependency in Rust into a header file and call it a day. > I find many libraries in C++ that don't pull 20 dependencies. I can find many libraries in Rust that don't pull 20 dependencies (mostly by searching crates written by people like the_mitsuhiko). Some people care, but they are a minority. If you truly care about this, like the_mitsuhiko does, write it with no dependencies. I, personally, try to minimize my dependencies, but there is a reason why most people don't care - it has little to no impact on them and saving time by NIH is better than not learning from history and reinventing wheel only square. --- Problem is: There are infinitely many of properties to improve (number of dependencies, byte size, compile time, run time, alignment, crates not made by X, time to market, reproducibility, compliance with law XYZKM, safety etc.) and not enough time or possibility space to do them all.

lolinder 2y ago
> Vendoring means, 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. This is not what vendoring means, this is called forking. Vendoring is just the copy+commit phase, not the modification part.
- deleted 2y ago
  [deleted]
- Ygg2 2y ago
  Dunno. That's what one project I worked on called it. Forking code on GH, pulling as submodules and maintaining it (most repos were unmaintained for years).
palata 2y ago
> 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).
- Ygg2 2y ago
  > 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.
  - palata 2y ago
    > 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.

by Ygg2 2y ago

lolinder 2y ago

> Vendoring means, 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. This is not what vendoring means, this is called forking. Vendoring is just the copy+commit phase, not the modification part.

deleted 2y ago
[deleted]
Ygg2 2y ago
Dunno. That's what one project I worked on called it. Forking code on GH, pulling as submodules and maintaining it (most repos were unmaintained for years).

palata 2y ago

> 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).

Ygg2 2y ago
> 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.
- palata 2y ago
  > 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.