oops, mailed the OP direct rather than the list. sorry.
-------- Originele bericht --------
Onderwerp: Re: another question on setting include paths for a project
Datum: Mon, 22 Mar 2010 15:58:28 +0000
Van: Jochem Maas <jochem@xxxxxxxxxxxxx>
Aan: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx>
Op 3/22/10 2:18 PM, Robert P. J. Day schreef:
>
> to recap regarding an earlier question i asked regarding extending
> include paths, i have an existing project (call it "proj" currently
> all under a top-level directory also named "proj") which can be SVN
> checked out anywhere under a user's home directory. so in my case, i
> might have my svn working copy under, say,
> /home/rpjday/stuff/work/proj/, and all proj-related content under
> that.
>
> at the moment, there are some subdirs under proj/ like "common" and
> "utils" and "debug", and all includes or requires throughout the
> working copy are currently and awkwardly of the form:
>
> include '../../proj/utils/somescript.php';
>
> in short, every script that needs to include another one somewhere
> else in the code structure sadly needs to know its precise relative
> location.
>
> my proposal is to get rid of most of that by:
>
> 1) having developers set a single env var PROJ_DIR in their login
> session, reflecting wherever the heck they checked out their
> working copy to, then ...
> 2) having said developers uniformly extend their directly callable PHP
> scripts with something at the very top like:
>
> set_include_path(getenv('PROJ_DIR') . PATH_SEPARATOR . get_include_path());
>
> not only will that let them simplify their command-line callable
> scripts to say just:
>
> include 'utils/somescript.php';
>
> also, as i read it, that newly-extended include path percolates down
> through all PHP scripts invoked directly or indirectly from this one,
> right? so while i could add that set_include_path() to every single
> PHP script everywhere in the code base, it's really only necessary to
> add it to those PHP scripts that people intend to *invoke* directly --
> every other script will pick it up automatically as it's called, is
> that correct? (did i phrase that meaningfully?)
>
> that was part one.
>
> the new additional complication is that some of those PHP scripts
> will manually construct HTTP POST requests and ship those requests off
> to PHP scripts that live under a public_html/ directory, whose
> scripts might *also* want to include some of those very same utils/ or
> common/ scripts but that modified include path will, of course, not
> carry across a POST request, so what's the standard way to similarly
> modify the include path of the scripts on the server end?
>
> (unsurprisingly, all those "server-side" PHP scripts are also part
> of the entire SVN checkout just so i can keep everything in the same
> place for testing.)
>
> so how can i have those "server-side" scripts extend their search
> path based on, perhaps, the same environment variable?
>
> thoughts?
I think the whole 'set an ENV var in their shell session' idea is overkill.
everything is checked out from svn, the structure of the project is known,
there is no reason not to use relative paths for the includes, there is
no need to tell the scripts where stuff is in this scenario - they can
work it out automatically.
the following might give you an idea for a bit of bootstrap code that's included
by everything:
define('INC_DIR', dirname(__FILE__));
this would allow all other code to use absolute paths and allow you to set
the include_path to ''.
how do the cmdline scripts know which URL to hit ... I would assume that this
URL can change depending on whose checkout it is and the context (dev/prod),
that means there is already a config file or some such - possibly a good place
to stick the include path or define the include dir.
... and now for something 'completey' different:
another trick I've used is to use custom ini settings in conjunction with
get_cfg_var() - each developer/installation would have their own custom ini
file (which you can store in svn too) .. the ini file would be symlinked to
from the dir php is setup to read additional ini files from, the contents of
the ini file would be something like:
[My Cool App]
my_cool_app.public_url = 'http://local.coolapp/';
my_cool_app.inc_dir = '/path/to/cool/app/';
you can then grab these values from anywhere using get_cfg_var('my_cool_app.inc_dir'),
often I find that additional config stuff is needed per installation - mostly related
to webserver setup (which sometimes differs somewhat between live and dev installs -
SSL may not be available/required/wanted and if it is IP addresses need to be hard coded,
apache may require you to use absolute paths, test systems may require IP restrictions, etc)
so I setup a dir structure like so:
<project>/cnf/targets/localhost.jochem/php
<project>/cnf/targets/localhost.jochem/httpd
<project>/cnf/targets/localhost.charlie/php
<project>/cnf/targets/localhost.charlie/httpd
<project>/cnf/targets/some.test.domain/php
<project>/cnf/targets/some.test.domain/httpd
I'd also maintain an example dir specifying minimum requirements for each install's configs:
<project>/cnf/targets/example/README
<project>/cnf/targets/example/php/mycoolapp.ini
<project>/cnf/targets/example/httpd/public.mycoolapp.conf
if there is a need to have php code look into the current installs cnf dir I'd
put a file called 'target' in <project>/cnf/ with the contents set to the
install dir in question (e.g. 'localhost.jochem') ... this file would be excluded
from SVN.
the file 'mycoolapp.ini' from the relevant target would be symlinked:
$ ln -s <project>/cnf/targets/localhost.jochem/php/mycoolapp.ini /etc/php.d/mycoolapp.ini
this would need to be done only once rather at the beginning of each shell session.
>
> rday
> --
>
> ========================================================================
> Robert P. J. Day Waterloo, Ontario, CANADA
>
> Linux Consulting, Training and Kernel Pedantry.
>
> Web page: http://crashcourse.ca
> Twitter: http://twitter.com/rpjday
> ========================================================================
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
