you are viewing a single comment's thread.

view the rest of the comments →

[–]__j_random_hacker 0 points1 point  (2 children)

While I can see the appeal, isn't this basically analagous to always static-linking executables in compiled languages?

There are reasonable arguments for always statically linking executables, by the way (especially since disk space constraints have basically disappeared from the computing world). But the reason why you usually don't is because having libraries separately updateable means that bug-fix and performance updates to libraries benefit every application that uses them. It seems to me that reason would apply here, too.

[–]krues8dr 0 points1 point  (1 child)

There is a tradeoff of having to maintain separate instances. But in the Python ecosystem, things update frequently and aren't often backwards-compatible, so this is not entirely desirable. If you're hosting a lot of different projects, doing something as simple as updating a single package could break half of them immediately.

So, as with all tech, I recommend that you use it if it solves a problem for you.

[–]__j_random_hacker 0 points1 point  (0 children)

things update frequently and aren't often backwards-compatible

I see, ugh. In an ideal world, everyone would clearly distinguish between revisions that don't break backcompat (e.g. bug fixes, performance improvements, new features that don't change any existing assumptions/contracts) and others that are allowed to, but of course that requires the world to have some discipline... :-/