[Gforge-devel] Hardcoded Paths in GForge

[Robert Nelson]

I'm confused; your response doesn't seem to answer my questions.  My
questions are specifically about how to handle the fopen cases, for which I
suggested creating a function that searches the include path for the file
rather than taking a hardcoded path.

The other question was how to handle the installation of plugins.  The
plugin installer needs to know the "/etc/gforge" path in order to install
the plugin's config.php and other files.  My suggestion for this was the
getConfigDirectory().  As I described in the message this function would NOT
use a hardcoded path.  It would search along the include path for the
local.inc file and return that directory.


> -----Original Message-----
> From: gforge-devel-bounces at lists.gforge.org [mailto:gforge-devel-
> bounces at lists.gforge.org] On Behalf Of Christian BAYLE
> Sent: Saturday, March 10, 2007 11:37 AM
> To: gforge-devel at lists.gforge.org
> Subject: Re: [Gforge-devel] Hardcoded Paths in GForge
> 
> The only required use of a path var is when you want to "fopen" a file
> which should be done as less as possible
> I would prefer not to have the need of any fixed path, and the
> getConfigDirectory would probably store a path.
> 
> I would prefer a convention that all plugin have a config.php file that
> have to be found in the path under some
> minimalist structured form like plugins/<pluginname>/config.php, so you
> can put all transparently e.g. in /etc/gforge or
> whatever place you put config files (It's more or less like this for
> many plugins but the path is
> plugins/<plugname>/etc/plugins/<plugname>/config.php which is not very
> convenient)
> 
> I would be tempted to propose to put all vars in a table, I'm not sure
> it would slow down page display, but it would have the convenient
> property to build easily config page
> 
> Indeed I think that only some db connection related vars are necessary
> in a file, and I would be tempted to remove the use of passwd, which I
> think is finally worst than allowing non passworded db connection to
> apache user.
> 
> Luxuous solution would be the propose the two possibilities, file or db.
> 
> Christian
> 
> 
> Robert Nelson wrote:
> >
> > Christian and I were discussing the hard-coded paths in GForge on the
> > IRC. As part of my changes I introduced a new configuration variable
> > sys_etc_path. This is used instead of the previously hardcoded
> > /etc/gforge in a number of files. Christian suggested, and I agreed,
> > that we should avoid manual configuration and make GForge self
> > configuring using the include path.
> >
> > Currently the sys_etc_path variable is used to form directory paths
> > which are checked for existence or to form file paths which are passed
> > to fopen. Both of these scenarios are easily handled using a routine
> > that searches the include path and returns the matching path.
> >
> > However the Plugin Manager is more problematic since it creates the
> > symlink so there isn't an existing file or path to search. I could
> > search for the local.inc file and then use the directory as the
> > equivalent of /etc/gforge. This could be packaged as a function
> > getConfigDirectory for example. Then the existing references to
> > /etc/gforge or sys_etc_path could be replaced with calls to this new
> > function.
> >
> > How does this sound? Would it address your concerns Christian? Anyone
> > have any better ideas?
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Gforge-devel mailing list
> > Gforge-devel at lists.gforge.org
> > http://lists.gforge.org/mailman/listinfo/gforge-devel
> >
> 
> _______________________________________________
> Gforge-devel mailing list
> Gforge-devel at lists.gforge.org
> http://lists.gforge.org/mailman/listinfo/gforge-devel