5 ms·

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.

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.
    - alexvitkov 1y ago
      > 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. If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately. Any software that has lives riding on it, if it has dependencies, must be certified against a specific version of them, that should 100% of the time, without exceptions, must be vendored with the software. > It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on. The exact opposite. Vendoring is the ONLY way to prevent the ABI madness of "v1.3.1 of libfoo exports libfoo_a but not libfoo_b, and v1.3.2 exports libfoo_b but not libfoo_c, and in 1.3.2 libfoo_b takes in a pointer to a struct that has a different layout." If you MUST have libfoo (which you don't), you link your version of libfoo into your blob and you never expose any libfoo symbols in your library's blob.
      - seba_dos1 1y ago
        You keep confirming that you don't know what you are talking about. The vendoring step happens at something like Yocto or equivalent and that's what ends up being certified, not random library repos.

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.
  - alexvitkov 1y ago
    > 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. If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately. Any software that has lives riding on it, if it has dependencies, must be certified against a specific version of them, that should 100% of the time, without exceptions, must be vendored with the software. > It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on. The exact opposite. Vendoring is the ONLY way to prevent the ABI madness of "v1.3.1 of libfoo exports libfoo_a but not libfoo_b, and v1.3.2 exports libfoo_b but not libfoo_c, and in 1.3.2 libfoo_b takes in a pointer to a struct that has a different layout." If you MUST have libfoo (which you don't), you link your version of libfoo into your blob and you never expose any libfoo symbols in your library's blob.
    - seba_dos1 1y ago
      You keep confirming that you don't know what you are talking about. The vendoring step happens at something like Yocto or equivalent and that's what ends up being certified, not random library repos.