Steve Holden <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > So, if fifteen different programs depend on library X, we'd have > > fifteen *separate* installations of library X on the same machine? > > > You need to get your opinions up to date. Fifteen copies of a single > library is nothing in terms of the code bloat that has happened over > the last forty years, and most of that bloat is for programmer > convenience, either in package development or distribution.
Thanks for the straw man, but I'll decline. The issue with multiple copies of the same library is *not* disk storage bloat, but violation of DRY: Don't Repeat Yourself. When the above putative library X is found to have a bug and needs to be upgraded to fix, it's wasteful of resources to have to track down *every* instance of that library, in all the places where separate packages expect to find it — and it's a recipe for omitting one or several of those multiple instances, thus getting hard-to-track errors in code that *should* exist in one place on the system. > While it's all very well to say that there should only ever be one > true version of a library this requires that developers constrain > themselves (sometimes in ways they consider unreasonable) to > backwards compatibility for the entire lifetime of their code. Not at all. If the package management system is designed well — like in most modern operating systems — new versions can be installed, and even relied upon by multiple packages, while the old one stays on the system for those packages that still haven't migrated to the new. The foolish part is to have multiple copies of the *same* code scattered around the system, with different packages looking for the same code in different places. > > And when it comes time to upgrade library X because a security > > flaw is discovered, each of the fifteen instances must be upgraded > > separately? > > > Yes. Better than upgrading a single library shared between fifteen > applications and having two of them break. Then allow the old library to stay on the system, in *one* single, known location, for the applications that need it; and the new library in *its* single known location for the applications that use it. > Agreed, but until we reach the ideal situation where everybody is > using the same package dependency system what's your practical > solution? The above benefits don't require "everybody is using the same package dependency system". They accrue one machine at a time, by making *that machine* less prone to the redundancy problems mentioned above. They also are incremental, and are beneficial to move towards; that is, even if the machine is using several package management systems, any movement towards unifying the package management is a reduction in duplication and hence a reduction in the associated problems. > "Self-contained" has the merit that nobody else's changes are going > to bugger about with my application on a customer's system. That's nice for you, the programmer. Package management and proper dependency declaration is a benefit to the customer (the one who owns the machine, not the programmer) since they can upgrade each package *once* per machine, and not have to hunt down all the places where a previous version may still be installed simply because it was convenient for the programmer. Yes, this requires good management of APIs for libraries on the part of the programmers of those libraries, and ensuring that a new version with the same API maintains its expected behaviour. It also requires that the programmer depending on those libraries declares dependencies properly. It's working fine for many operating systems — even in the absence of a universal package management system. > The extra disk space is a small price to pay for that guarantee. Hopefully you can discard this straw man argument and engage the actual problems of redundant installations of identical code packages. -- \ "It's not what you pay a man, but what he costs you that | `\ counts." -- Will Rogers | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
