4 ms·

What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download

by hasenj 9y ago

What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.

pjmlp 9y ago
If the new version has moved from Git to new suppa-duppa source control, you will need to update all import statements after replacing it on the vendors directory. With proper package names via a package manager, usually the name stays the same.
stubish 9y ago
Managing vendoring yourself is impractical once you end up with more than a handful of dependencies, or once one of your dependencies pulls in more than a handful of transient dependencies. A larger project will have hundreds of dependencies and transient dependencies, and if you just pull them into your vendor directory and forget about them then you have a problem waiting to happen.
- hasenj 9y ago
  I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I prefer to be conservative about adding dependencies, and to always manually include them into the project.
  - stubish 9y ago
    You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of your dependencies use... all for a microservice and administrative tool... and one part of the larger project.
    - hasenj 9y ago
      That's the definition of not being conservative about adding dependencies.
      - stubish 9y ago
        Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably usability since your time is limited.
        hasenj 9y ago
        That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > database utilities Not needed. > gRPC framework Not needed. > monitoring & metrics Not needed. > CLI & configuration tools NOT NEEDED! .. etc. > Drop any item on that list and you are either losing capabilities or have more software to implement yourself What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package. Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them. Every dependency you add is a potential point of failure and headaches. Just like every layer of abstraction you create. The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost. > Cobra Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries. > Viper How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever? How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency. > it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto You don't even need to re-implement anything. Just do the simplest thing that works using the standard library. You know the standard library comes with a crypto package, right? The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.

by hasenj 9y ago

pjmlp 9y ago

If the new version has moved from Git to new suppa-duppa source control, you will need to update all import statements after replacing it on the vendors directory. With proper package names via a package manager, usually the name stays the same.

stubish 9y ago

Managing vendoring yourself is impractical once you end up with more than a handful of dependencies, or once one of your dependencies pulls in more than a handful of transient dependencies. A larger project will have hundreds of dependencies and transient dependencies, and if you just pull them into your vendor directory and forget about them then you have a problem waiting to happen.

hasenj 9y ago
I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I prefer to be conservative about adding dependencies, and to always manually include them into the project.
- stubish 9y ago
  You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of your dependencies use... all for a microservice and administrative tool... and one part of the larger project.
  - hasenj 9y ago
    That's the definition of not being conservative about adding dependencies.
    - stubish 9y ago
      Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably usability since your time is limited.
      - hasenj 9y ago
        That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > database utilities Not needed. > gRPC framework Not needed. > monitoring & metrics Not needed. > CLI & configuration tools NOT NEEDED! .. etc. > Drop any item on that list and you are either losing capabilities or have more software to implement yourself What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package. Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them. Every dependency you add is a potential point of failure and headaches. Just like every layer of abstraction you create. The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost. > Cobra Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries. > Viper How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever? How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency. > it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto You don't even need to re-implement anything. Just do the simplest thing that works using the standard library. You know the standard library comes with a crypto package, right? The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.