This is probably not an original idea. I am not one of those who complain about Oracle's acquisition, as a part of Sun Microsystems, of the MySQL mark and the associated software. Larry Ellison is plenty shrewd enough to make money out of open source - OK, maybe not as much as from proprietary, but when you are Larry Ellison you might figure you are getting close to enough anyway. Or maybe not.
But suppose someone evil in the Ellison empire were to decide to bury MySQL for ever, it strikes me that all they would have to do would be to bundle it under the Oracle installer. This gargantuan framework with basic Java look-and-feel and often totally inadequate error handling (disclaimer: I have little recent experience of Oracle, but I have used their products since 1986 or thereabouts and would be surprised if things had changed radically) would be quite enough to deter anyone who hadn't already forked over huge amounts of money for the software behind it. A free software release would simply not be worth the pain.
"Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C Clarke
Musings from the technological frontier
Showing posts with label installer. Show all posts
Showing posts with label installer. Show all posts
July 7, 2010
March 21, 2008
Packaging Python
There's an extensive discussion at the moment on the python-dev list about how python modules and applications should be packaged up in future. This all relates to the distutils and setuptools features, which are great when they work and horrible when they don't. There seems to be general agreement that an uninstall feature would be useful.
My own point of view is that there are different requirements for installing applications for end users and modules for developers. In the former case I believe it would nowadays be easiest and least error-prone if each (Python) application were installed with its own interpreter and all dependencies. While this seems horribly wasteful, it neatly avoids any kind of version lock-in and allows application upgrades. In the latter case then something more like the traditional setup.py install is more appropriate, and the installation probably doesn't need to be recorded in whatever mechanism the system uses to record installed applications (e.g. Add/Remove Programs under Windows).
Whatever the result, it does appear that 2.6 could get us closer to a universal solution to installation problems.
My own point of view is that there are different requirements for installing applications for end users and modules for developers. In the former case I believe it would nowadays be easiest and least error-prone if each (Python) application were installed with its own interpreter and all dependencies. While this seems horribly wasteful, it neatly avoids any kind of version lock-in and allows application upgrades. In the latter case then something more like the traditional setup.py install is more appropriate, and the installation probably doesn't need to be recorded in whatever mechanism the system uses to record installed applications (e.g. Add/Remove Programs under Windows).
Whatever the result, it does appear that 2.6 could get us closer to a universal solution to installation problems.
Subscribe to:
Posts (Atom)