David Cournapeau a écrit :
But even though, I doubt buildout is what I am after: chroot-like sandboxing for example, is crucial (and for what it worths, it is a standard practice in the unix deployment world).
What I use is kind of besides the point, though. What matters is to have a standard core on top of which people can build their tools: a core in the stdlib, and buildout-based, scons-based, whatever-based tools on top. If you have an API to retrieve where things are put, how they are built and so on, everyone can be happy with the tool he prefers.
For your chrooting/API purposes, you can have a look to minitage, it's all his goals. But even buildout can provide you a basic isolation layer.
Well, buildout.cfg is exacltly that file for me, for both cases ;-)
I may not have been clear: by single file, I mean an installer, which needs to work offline, and is as integrated as possible in the user system. This mean msi, dmg, rpm, etc... A buildout.cfg can't possible be further from what I want in those cases.
What about using both ? If it is for releasing final softwares for "non-developers", just archive the resulting buildout infra. from the targeted host and make a package from there. Many people there do in that way (rpm, or so). As a developer, you ll have the flexibility and reliability of buildout, and you ll assure to your users to use their lovely system package manager which install a locally tarball of you whole buildout based packaged software. No need to be online there. On the other hand, buildout can work totally offline if you have all your requirements fulfilled. -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF