--- On Mon, 8/24/09, Chad
<innocentkiller(a)gmail.com> wrote:
Why skip trying to find the location? If
MW_INSTALL_PATH is already
missing, what have we got to lose from trying to guess the
location? The vast majority of people don't screw with the default
structure, so it should be just fine.
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.
Except that the cons are mostly hypothetical. I don't believe anyone
except you has actually proposed restructuring the extensions directory.
But even if we do, it still wouldn't affect most users because A) There
aren't that many extensions that add command line utilities (several
extensions also have scripts and hook based extensions so wouldn't
neatly fit into such categories) and B) Most users don't checkout the
entire extensions directory, just the few extensions they're actually
going to use, so they can continue to put them all in the same directory.
It may be, technically, a slight improvement to code quality, but its
arguably a degradation to end-user experience. It makes things slightly
easier for developers in the event of a hypothetical change (though
time-wise, its really only a benefit after the second such change) but
makes it so things that have "just worked" for years for users no longer
work without changing settings or adding extra command line parameters.
--
Alex (wikipedia:en:User:Mr.Z-man)