David Cournapeau wrote: >> I won't argue for setuptools' implementation of multi-version. It >> sucks. But multi-version can be done well. Sonames in C libraries are >> a simple system that does this better. > > I would say simplistic instead of simple :) what works for C won't > necessarily work for python - and even in C, library versioning is not > used that often except for a few core libraries. Library versioning > works in C because C model is very simple. It already breaks for C++.
I'm not sure what you're talking about here. Library versioning is used for practically every library on a Linux system. My limited exposure to the BSDs and Solaris was the same. (If you're only talking Windows, well; does windows even have Sonames?) I can name only one library that isn't versioned in Fedora right now and may have heard of five total. Perhaps you are thinking of library symbols? If so, there are only a few libraries that are using that. But specifying backwards compatibility via soname is well known and ubiquitous. > More high-level languages like C# already have a more complicated > scheme (GAC) - and my impression is that it did not work that well. > The SxS for dll on recent windows to handle multiple version is a > nightmare too in my (limited) experience. > Looking at C#/Mono/.net for examples is perfectly horrid. They've taken inferior library versioning and bad development practices and added technology (the GAC) as the solution. If you want an idea of what python should avoid at all costs, look to that arena for your answer. * Note that setuptools' multi-version implementation shares some things in common with the GAC. For instance, using directories to separate versions instead of filenames. setuptools' implementation could be made better by studying the GAC and taking things like caching of lookups from it but I don't encourage this... I think the design itself is flawed. -Toshio
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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