David Cournapeau wrote: > On Wed, Mar 25, 2009 at 1:45 AM, Toshio Kuratomi <a.bad...@gmail.com> wrote: >> David Cournapeau wrote: >>> 2009/3/24 Toshio Kuratomi <a.bad...@gmail.com>: >>>> Steve Holden wrote: >>>> >>>>> Seems to me that while all this is fine for developers and Python users >>>>> it's completely unsatisfactory for people who just want to use Python >>>>> applications. For them it's much easier if each application comes with >>>>> all dependencies including the interpreter. >>>>> >>>>> This may seem wasteful, but it removes many of the version compatibility >>>>> issues that otherwise bog things down. >>>>> >>>> The upfront cost of bundling is lower but the maintenance cost is >>>> higher. For instance, OS vendors have developed many ways of being >>>> notified of and dealing with security issues. If there's a security >>>> issue with gtkmozdev and the python bindings to it have to be >>>> recompiled, OS vendors will be alerted to it and have the opportunity to >>>> release updates on zero day, the day that the security announcement goes >>>> out. >>> I don't think bundling should be compared to depending on the system >>> libraries, but as a lesser evil compared to requiring multiple, >>> system-wide installed libraries. >>> >> Well.. I'm not so sure it's even a win there. If the libraries are >> installed system-wide, at least the consumer of the application knows: >> >> 1) Where to find all the libraries to audit the versions when a security >> issue is announced. >> 2) That the library is unforked from upstream. >> 3) That all the consumers of the library version have a central location >> to collaborate on announcing fixes to the library. > > Yes, those are problems, but installing multi libraries have a lot of > problems too: > - quickly, by enabling multiple version installed, people become very > sloppy to handle versions of the dependencies, and this increases a > lot the number of libraries installed - so the advantages above for > system-wide installation becomes intractable quite quickly
This is somewhat true. Sloppiness and increased libraries are bad. But there are checks on this sloppiness. Distributions, for instance, are quite active about porting software to use only a subset of versions. So in the open source world, there's a large number of players interested in keeping the number of versions down. Using multiple libraries will point people at where work needs to be done whereas bundling hides it behind the monolithic bundle. > - bundling also supports a real user-case which cannot be solved by > rpm/deb AFAIK: installation without administration privileges. This is only sortof true. You can install rpms into a local directory without root privileges with a commandline switch. But rpm/deb are optimized for system administrators so the documentation on doing this is not well done. There can also be code issues with doing things this way but those issues can affect bundled apps as well. And finally, since rpm's primary use is installing systems, the toolset around it builds systems. So it's a lot easier to build a private root filesystem than it is to cherrypick a single package. It should be possible to create a tool that merges a system rpmdb and a user's local rpmdb using the existing API but I'm not aware of any applications built to do that yet. > - multi-version installation give very fragile systems. That's > actually my number one complain in python: setuptools has caused me > numerous headache, and I got many bug reports because you often do not > know why one version was loaded instead of another one. > 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. > So I am not so convinced multiple-version is better than bundling - I > can see how it sometimes can be, but I am not sure those are that > important in practice. > Bundling is always harmful. Whether multiple versioning is any better is certainly debatable :-) >> No. This is a social problem. Good source control only helps if I am >> tracking upstream's trunk so I'm aware of the direction that their >> changes are headed. But there's a wide range of reasons that >> application developers that bundle libraries don't do that: >> >> 1) not enough time in a day. I'm working full-time on making my >> application better. Plus I have to update all these bundled libraries >> from time to time, testing that the updates don't break anything. I >> don't have time to track trunk for all these libraries -- I barely have >> time to track releases. > > Yes, but in that case, there is nothing you can do. Putting everything > in one project is always easier than splitting into modules, coding > and deployment-wise. That's just one side of the speed of development > vs maintenance issue IMHO. > >> 3) This doesn't help with the fact that my bundled version of the >> library and your bundled version of the library are being developed in >> isolation from each other. This needs central coordination which people >> who believe bundling libraries are very unlikely to pursue. > > As above, I think that in that case, it will happen whatever tools are > available, so it is not a case worth being pursued. > I'm confused -- if it will happen whatever tools are available, how does "good source control" solve the issue? I'm saying that this is not an issue that can be solved by having good source control... it's a social issue that has to be solved by people learning to avoid bad practices. -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
