Then we shall never agree. I believe its pretty much
accepted that we *like* the approach of "use the
environment variable if it's available, guess where we
think it is when it's not" is good. Of course, the env
variable is best: that's why it was added. What I fail to
understand is why trying to guess the path when the
variable isn't around is such a bad idea?
In my mind, the logic should be: 1) try the variable, 2)
try to guess the path if we don't know #1, and 3) fail.
You seem to be wanting to take out step 2, which makes
zero sense to me. Most installs never touch the default
directory structure, and should be able to fail back to
that just fine.
-Chad
On Aug 24, 2009 1:30 PM, "dan nessett" <dnessett(a)yahoo.com> wrote:
--- On Mon, 8/24/09, Chad <innocentkiller(a)gmail.com> wrote: > Why skip
trying to find the location?...
That's a reasonable question, stating in another way the useful maxim, "if
it ain't broke, don't fix it." The problem is I think it's
"broke".
Here is my take on the pros/cons of leaving things unchanged:
Pros:
* Some administrators are used to simply typing the line php <utility>.php.
Making them type:
MW_INSTALL_PATH=/var/wiki/mediawiki php <utility>.php
would be inconvenient.
In answer to this, for the MW installations running on unix, it is pretty
simple to alias "MW_INSTALL_PATH=/var/wiki/mediawiki php" and put the
definition into .bash_profile (or the appropriate shell initialization
script). This is a one time effort and so the change isn't as onerous as it
might seem. I assume there is a similar tactic available for windows
systems.
Cons:
* The use of file position dependent code is a problem during development
and much less of a problem during installation and production (as you
suggest). Right now there are ~400 sub-directories in the extensions
directory. It seems to me reorganization of the extensions directory would
help understanding the relationship between individual extensions and the
core. For example, having two subdirectories, one for cli utilities and
another for hook based extensions would clarify the role each extension
plays. However, currently there are 29 extensions where $IP is set using the
relative position of the file in the MW directory structure (a couple of
other extensions set $IP based on MW_INSTALL_PATH). Reorganizing the
directory structure has the potential of breaking them.
* CLI utilities are moved around for reasons other than a reorganization of
the extensions directory. For example, as I understand it, DumpHTML was
moved from maintenance/ to extensions/. dumpHTML.php sets $IP based on its
relative position in the distribution tree. It was a happy coincidence that
when it was moved, its relative position didn't change. However, it is
unreasonable to think such reclassifications will always be as fortunate.
Since the cons outweigh the pros, I remain convinced that the change I
suggested (using die()) improves the code.
Dan _______________________________________________ Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l