4 ms·

Yes, I do, because this isn't just about my source-code, but about the dependencies of dependencies.

grey-area 6y ago
The two approaches to this are to force resolving dependencies (can be painful and require humans), or duplicate code (can cause bugs). There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you do it routinely you'd see bugs due to shared locks, state, or changed data structures - it breaks assumptions about pkg globals for example, an important part of the language used extensively in the stdlib.
- yxhuvud 6y ago
  Or even conflicts rising from competing use of state space in some other app. For example, if your database have a limited set of connections it can set up then you absolutely don't want different dependencies to handle connection pooling by themselves.
- imtringued 6y ago
  >There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you don't duplicate versions then you will have to wait for every single library in existence to update to the latest major version. This can take decades and still fail. Just take a look at Python 3.
stubish 6y ago
So yes, you want that. But how about the next question? The dependencies of your dependencies may conflict with different versions of themselves. Because nobody thought 'what happens if there is another version of this code running in a different namespace'. And nobody tested it, so you are trusting to luck rather than any sort of rigor. Thankfully, the conflicts when they happen are usually fairly obvious (two copies of the connection pool built into your database driver, or a crash on startup because the run-once initialization ends up being run twice). But it could be more subtle, like multiple versions of the dependency that handles logging not sharing a mutex and your logs end up interleaved or corrupt under load.

The two approaches to this are to force resolving dependencies (can be painful and require humans), or duplicate code (can cause bugs). There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you do it routinely you'd see bugs due to shared locks, state, or changed data structures - it breaks assumptions about pkg globals for example, an important part of the language used extensively in the stdlib.

yxhuvud 6y ago
Or even conflicts rising from competing use of state space in some other app. For example, if your database have a limited set of connections it can set up then you absolutely don't want different dependencies to handle connection pooling by themselves.
imtringued 6y ago
>There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you don't duplicate versions then you will have to wait for every single library in existence to update to the latest major version. This can take decades and still fail. Just take a look at Python 3.

stubish 6y ago

So yes, you want that. But how about the next question? The dependencies of your dependencies may conflict with different versions of themselves. Because nobody thought 'what happens if there is another version of this code running in a different namespace'. And nobody tested it, so you are trusting to luck rather than any sort of rigor. Thankfully, the conflicts when they happen are usually fairly obvious (two copies of the connection pool built into your database driver, or a crash on startup because the run-once initialization ends up being run twice). But it could be more subtle, like multiple versions of the dependency that handles logging not sharing a mutex and your logs end up interleaved or corrupt under load.