> If the problem is to get a recent enough version of the library, then > the library would better be installed "locally", for the application. > If it is too much a problem because the application depends on > billions of libraries which are 6 months old, the problem is to allow > such a dependency in the first place. What kind of nightmare would it > be if programs developed in C would required a C library which is 6 > months old ? That's exactly what multiple-versions installations > inflict on us. That's great for testing, development. But for > deployment on end-user machines, the whole thing is a failure IMO.
I see this as a consequence of Web 2.0, and open source: Publish early, publish often, make the pieces you publish as tiny as possible to maximize reuse :-( If people invent a new marshaling format every year (XML-RPC, SOAP, JSON, YAML, ...), you *have* to use a just-published library to follow the hype curve. If you have been raised in this tradition, you are shocked by the number of modules in the Python library, and wish for this dinosaur to die. Apparently, deployment to end user machines is not so much of an issue usually, since the mess will live on the web servers, and not on everybody's end user machine. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com