I'm going to put the case, semi-seriously, that the 'solution' to the problem of distributing packages is to use interscript. I'll try to distinguish what works now, what is planned, and what I have no real idea about yet. For those not familiar with it: it is a source format in which 1) code 2) documentation 3) installation and building instructions can all be encoded. First, interscript allows all packages to be archived in a single text file. [Works now]. It is possible to store encoded binary if it is _really_ necesssary [planned]. The client can extract stuff from the archive with a command line tool [works now], or by embedding the package in another application [works now]. The client decides if documentation is to be generated [works now] and if so, what format it should be in [works now: plain text, flat HTML, advanced HTML, Latex2e, Lambda work now, XML planned] The client decides what language the documentation is to be produced in [planned] The client determines where the documentation is installed [works now] and where the code is installed [works now]. The package automatically builds any components written in C or C++ [works now]. It can configure itself for any platform/user/site/ preferences [planned, what works now depends on the ability to 'introspect' the information from Python itself, which is not enough] The package automatically tests everything. [Works now, but more work is required to create a proper test harness] Interscript can read source directly off the Internet [FTP and HTTP works now]. Interscript can read compressed archives [planned]. Interscript can generate interscript archives from any existing packages [sort of works :-] ----------------------------------------------------------- There is a full categorical installation/version control/dependency mechanism. [Some plans: much help needed here!!!] ----------------------------------------------------------- So there you have it: interscript already does Almost Everything (TM) a disttribution mechanism requires, and it will support almost all programming languages, not just C/C++/Java/Python, although support for these four languages is the highest priority (because they're needed for interscript itself). Interscript is written entirely in Python, although there are some C modules which do optimisations, and there is some dependency on external tools (C/C++/Java compilers, patch, diff) for full functionality. ----------------------------------------------------------- Objection: Interscript is too big. Answer: At present, everything is bundled togther in an experimental package. Because there is no standard or simple way to distribute the separate components separately. The intent is to use this experimental version to create the tools needed to unbundle itself. This is called 'bootstrapping' <grin> Objection: I'm not interesting in Literate Programming. Answer: Irrelevant. Interscript is a build/test/install environment. The mechanism includes a lot of support for literate programming, but this doesn't _have_ to be used by anyone. Objection: My packages aren't built using interscript, I don't want to convert them, it's too much work. Answer: an automated tool can package up all existing distributions. All that is required is listing the files to be packaged, with an indication if they're text or binary. Objection: not enough is working properly yet. Answer. This is a valid objection. More people working on the components would help remove this objection. See next post. ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia