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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
