Am 19.10.2006 um 11:42 schrieb Luis Matos: >> However, you will still be able to configure things like shared >> templates and wiki pages directories. This would be done as options >> to the "trac-admin initenv" command, for example: >> >> trac-admin /var/trac/proj initenv \ >> --templates /etc/trac/templates \ >> --wiki-pages /etc/trac/wiki-pages >> > about trac admin. > > It's good for who has access to the machine. > > Normally, with multiple projects project admins don't have it.
There's a web administration interface available as a plugin that will be merged into core for 0.11. Multiple projects are a different story. Trac at this point is essentially a single-project tool. It provides *some* convenience features that make it easier to manage multiple projects... but if you want a web interface that allows you to create or delete projects you'll need to write that yourself. > Although, using trac-admin to create the project is not straight > forward, especifying several variables. I don't see why it's not straightforward. Note that in 0.11 trac- admin will become simpler for simple setups (no required arguments, for example), and provide more flexibility to power-users (more options). > for overdue that, my propose is to install in /etc/trac some files to > configure that that will overdue the trac files. "overdue"? I think you're using the wrong word here :-P >> These command-line options are stored as regular config options in >> the projects trac.ini. Note that Trac would not automatically create >> those directories on installation, that'd be the responsibility of >> either the admin or the distro package. >> > > Abou trac.ini. > It is easier to have a full trac.ini, or some other file, that > would be > easy to setup, again, as a config file, it should be in /etc/trac. First, Trac needs to run on non-unix platforms, where /etc/trac would either not be available, or not make sense. Second, when we move to setuptools, we will have to stop scattering files around the file system at install time. That means *no* /usr/ share/trac, and also *no* /etc/trac. That does however not mean that e.g. a Debian package could not set those up... >> Now, to make handling of multi-environment installs somewhat easier, >> I would suggest we inspect a number of environment variables that can >> be used to provide defaults. So for example, you could define: >> >> TRAC_TEMPLATES_DIR = /etc/trac/templates >> TRAC_WIKI_PAGES_DIR = /etc/trac/wiki-pages > > Why don't you make a place where the package mantainers could > change this. > It was siteconfig.py ... is it still? it should be important to > define a > config dir at install. I said in my response that "siteconfig.py is going to be removed". The whole idea is to remove that stuff and rely only on environment variables, trac.ini options, and trac-admin options. A Debian package could, however, make this more convenient/familiar for Debian users. For example, create an /etc/conf.d/trac file that lists those environment variables, and automatically source them when a trac script is run. And create/populate an /etc/trac directory. However, the responsibility of all that is outside of Trac itself. We just want to make sure that package maintainers *can* do those things. > what about default roadmap. Default icons, default css ... "Default roadmap" makes no sense. The default CSS is not intended to be modified/replaces. Admins can *override* it using a site stylesheet. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev -~----------~----~----~----~------~----~------~--~---
