I have a vague idea a new bdist format that I'd like to bounce off you all before I start thinking about it too hard. In other words, please shoot holes in it.
The bdist_dumb formats have exactly that problem: they're too dumb. They basically create a tarfile (or other archive type) with full pathnames in it and that's it. However, there could be a bdist_xxx which would create a tarfile in which everything was relative, but the directory parts are magic. If you extract this tarfile with a normal tar you would get a directory with under it directories INSTALL_BASE, INSTALL_PLATBASE, ROOT, etc etc etc. Or maybe all these would be rooted in a xxx/platform.machine.version directory, probably a better idea. The tar file would also contain the setup.py script.
The next part of the idea is that distutils would also learn about an install_xxx command. The default version of this command would simply copy the relevant files from xxx/platform.machine.version to their required locations, but it could of course be customized by the author of the setup script.
The final part of the idea is that "install" gets a bit of magic so it notices it is being run from an xxx installation directory. In this case it doesn't go through the build/install sequence, but quickly calls install_xxx. I'm not sure about the magic needed, it could test for the current directory only containing setup.py and xxx (and maybe a couple of files like README and such), it could test for missing source files, I'm not really sure. And maybe this whole bit of magic isn't needed, and the end user will just have to learn to type "install_xxx", if we find a good enough name for xxx. -- - Jack Jansen Jack.Jansen@oratrix.com http://www.cwi.nl/%7Ejack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
On Sun, 2003-02-23 at 16:31, Jack Jansen wrote:
The bdist_dumb formats have exactly that problem: they're too dumb. They basically create a tarfile (or other archive type) with full pathnames in it and that's it. However, there could be a bdist_xxx which would create a tarfile in which everything was relative, but the directory parts are magic. If you extract this tarfile with a normal tar you would get a directory with under it directories INSTALL_BASE, INSTALL_PLATBASE, ROOT, etc etc etc. Or maybe all these would be rooted in a xxx/platform.machine.version directory, probably a better idea. The tar file would also contain the setup.py script.
I think the problem is not so much in distributing binaries as generating the binaries and matching them to the user's system. This isn't a problem with pure python modules but it is a significant problem with non pure modules. For example, wxPython requires the wxWindows libraries and due to various issues you can't really create a generic wxPython binary and expect it to work on all versions of a given os. If you try to provide binaries for different versions of a binary, you'll quickly end up with a huge number of environments that you need to support. For linux systems alone, you'll need to support redhat 7.x,redhat 8.x, debian 3.0, and one or two versions of mandrake just to support some of the most popular distributions. Add in the *BSD systems, solaris, and windows and you have a huge task ahead of you.
The best option at the moment would probably be to go with the traditional source install and compile on unix based systems along with something like bdist_dumb (but with a little more intelligence) and a binary install for windows. The bdist_dumb option would provide a basic binary install but should be something that requires some conscious decision so that the user realizes that the binary install will probably not work unless the user's system matches the system the module was compiled on.
Jack Jansen wrote:
I have a vague idea a new bdist format that I'd like to bounce off you all before I start thinking about it too hard. In other words, please shoot holes in it.
The bdist_dumb formats have exactly that problem: they're too dumb. They basically create a tarfile (or other archive type) with full pathnames in it and that's it. However, there could be a bdist_xxx which would create a tarfile in which everything was relative, but the directory parts are magic. If you extract this tarfile with a normal tar you would get a directory with under it directories INSTALL_BASE, INSTALL_PLATBASE, ROOT, etc etc etc. Or maybe all these would be rooted in a xxx/platform.machine.version directory, probably a better idea. The tar file would also contain the setup.py script.
The next part of the idea is that distutils would also learn about an install_xxx command. The default version of this command would simply copy the relevant files from xxx/platform.machine.version to their required locations, but it could of course be customized by the author of the setup script.
The final part of the idea is that "install" gets a bit of magic so it notices it is being run from an xxx installation directory. In this case it doesn't go through the build/install sequence, but quickly calls install_xxx. I'm not sure about the magic needed, it could test for the current directory only containing setup.py and xxx (and maybe a couple of files like README and such), it could test for missing source files, I'm not really sure. And maybe this whole bit of magic isn't needed, and the end user will just have to learn to type "install_xxx", if we find a good enough name for xxx.
xxx = prebuilt ?! After all, that what this seems to be about :-)
-
Jack Jansen -
M.-A. Lemburg -
Suchandra Thapa