6 ms·

The argument here is (in brief) "Package management is hell, package managers are evil. So let's handle the hell manually to feel the pain better". And honestl

by adev_ 1y ago

The argument here is (in brief) "Package management is hell, package managers are evil. So let's handle the hell manually to feel the pain better". And honestly speaking: It is plain stupid. We can all agree that abusing package management with ~10000 of micro packages everywhere like npm/python/ruby does is completely unproductive and brings its own considerable maintenance burden and complexity. But ignoring the dependency resolution problem entirely by saying "You do not need dependencies" is even dumber. Not every person is working in an environment where shipping a giant blob executable built out of vendored static dependencies is even possible. This is a privilege of the Gamedev industry has and the author forgets a bit too easily it is domain specific. Some of us works in environment where the final product is an agglomerate of >100 of components developed by >20 teams around the world. Versioned over ~50 git repositories. Often mixed with some proprietary libraries provided by third-party providers. Gluing, assembling and testing all of that is far beyond the "LOL, just stick to the SDL" mindset proposed here. Some of us are developing libraries/frameworks that are used embedded in >50 products with other libraries with a hell of multiples combinations of compilers / ABI / platforms. This is not something you want to test nor support without automation. Some of us have to maintain cathedrals that are constructed over decades of domain specific knowhow (Scientific simulators, solvers, Petrol prospection tools, financial frameworks, ... ) in multiple languages (Fortran, C, C++, Python, Lua, ...) that can not just be re-written in few weeks because "I tell you: dependencies sucks, Bro" Managing all of that manually is just insane. And generally finishes with an home-made half-baked bunch of scripts that try to badly mimic the behavior of a proper package manager. So no, there is no replacement for a proper package manager: Instead of hating the tool, just learn to use it. Package manager are tools, and like every tool, they should be used Wisely and not as a Maslow's Hammer.

zahlman 1y ago
I mostly agree, but > Some of us works in environment where the final product is an agglomerate of >100 of components developed by >20 teams around the world. Versioned over ~50 git repositories. Often mixed with some proprietary libraries provided by third-party providers. Gluing, assembling and testing all of that is far beyond the "LOL, just stick to the SDL" mindset proposed here. Does this somehow prevent you from vendoring everything?
- pjc50 1y ago
  It certainly gets in the way. The more dependencies, the more work it is to update them, especially when for some reason you're choosing _not_ to automate that process. And the larger the dependencies, the larger the repo. Would you also try to build all of them on every CI run? What about the non-source dependencies, check the binaries into git?
- adev_ 1y ago
  > Does this somehow prevent you from vendoring everything? Yes. Because in these environment soon or later you will be shipping libraries and not executable. Shipping libraries means that your software will need to be integrated in other stacks where you do not control the full dependency tree nor the versions there. Vendoring dependencies in this situation is the guarantee that you will make the life of your customer miserable by throwing the diamond dependency problem right in their face.
  - alexvitkov 1y ago
    You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it. In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I somehow don't have to "manage a dependency tree" and "resolve peer dependency conflicts" when using them.
    - adev_ 1y ago
      > You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it. And you just don't know what you are talking about. If I am providing (lets say) a library that provides some high level features for a car ADAS system on top of a CAN network with a proprietary library as driver and interface. This is not up to me to fix or choose the library and the driver version that the customer will use. He will choose the certified version he will ship, he will test my software on it and integrate it. Vendoring dependency for anything which is not a final product (product as executable) is plain stupid. It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on. If you want to vendor, do vendor, but stick to executables with well-defined IPC systems.
gingerBill 1y ago
I am not sure how you got this conclusion from the article. > So let's handle the hell manually to feel the pain better This is far from my position. Literally the entire point is to make it clearer you are heading to dependency hell, rather than feel the pain better whilst you are there. I am not against dependencies but you should know the costs of them and the alternatives. Package managers hide the complexity, costs, trade-offs, and alternative approaches, thus making it easier to slip into dependency hell.
- adev_ 1y ago
  > I am not against dependencies but you should know the costs of them and the alternatives. You are against the usage of a tool and you propose no alternative. Handling the dependency by vendoring them manually, like you propose in your blog, is not an alternative. This is an over simplification of the problem (and the problem is complex) that can be applied only to your specific usage and domain.
  - gingerBill 1y ago
    It is an alternative, just clearly not one you like. And it's not an oversimplification of the problem. Again, what is wrong with saying you should know the costs of the dependencies you include AND the alternative approaches of not using the dependencies?—e.g. using the standard library, writing it yourself, using another dependency already that might fit, etc.

by adev_ 1y ago

zahlman 1y ago

I mostly agree, but > Some of us works in environment where the final product is an agglomerate of >100 of components developed by >20 teams around the world. Versioned over ~50 git repositories. Often mixed with some proprietary libraries provided by third-party providers. Gluing, assembling and testing all of that is far beyond the "LOL, just stick to the SDL" mindset proposed here. Does this somehow prevent you from vendoring everything?

pjc50 1y ago
It certainly gets in the way. The more dependencies, the more work it is to update them, especially when for some reason you're choosing _not_ to automate that process. And the larger the dependencies, the larger the repo. Would you also try to build all of them on every CI run? What about the non-source dependencies, check the binaries into git?
adev_ 1y ago
> Does this somehow prevent you from vendoring everything? Yes. Because in these environment soon or later you will be shipping libraries and not executable. Shipping libraries means that your software will need to be integrated in other stacks where you do not control the full dependency tree nor the versions there. Vendoring dependencies in this situation is the guarantee that you will make the life of your customer miserable by throwing the diamond dependency problem right in their face.
- alexvitkov 1y ago
  You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it. In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I somehow don't have to "manage a dependency tree" and "resolve peer dependency conflicts" when using them.
  - adev_ 1y ago
    > You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it. And you just don't know what you are talking about. If I am providing (lets say) a library that provides some high level features for a car ADAS system on top of a CAN network with a proprietary library as driver and interface. This is not up to me to fix or choose the library and the driver version that the customer will use. He will choose the certified version he will ship, he will test my software on it and integrate it. Vendoring dependency for anything which is not a final product (product as executable) is plain stupid. It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on. If you want to vendor, do vendor, but stick to executables with well-defined IPC systems.

gingerBill 1y ago

I am not sure how you got this conclusion from the article. > So let's handle the hell manually to feel the pain better This is far from my position. Literally the entire point is to make it clearer you are heading to dependency hell, rather than feel the pain better whilst you are there. I am not against dependencies but you should know the costs of them and the alternatives. Package managers hide the complexity, costs, trade-offs, and alternative approaches, thus making it easier to slip into dependency hell.

adev_ 1y ago
> I am not against dependencies but you should know the costs of them and the alternatives. You are against the usage of a tool and you propose no alternative. Handling the dependency by vendoring them manually, like you propose in your blog, is not an alternative. This is an over simplification of the problem (and the problem is complex) that can be applied only to your specific usage and domain.
- gingerBill 1y ago
  It is an alternative, just clearly not one you like. And it's not an oversimplification of the problem. Again, what is wrong with saying you should know the costs of the dependencies you include AND the alternative approaches of not using the dependencies?—e.g. using the standard library, writing it yourself, using another dependency already that might fit, etc.