Re: Why doesn't PEAR install package docs, tests into separate channel directory?
| From: | Brett Bieber | Date: | Wed, 11 Apr 2007 00:19:54 +0000 |
| Subject: | Re: Why doesn't PEAR install package docs, tests into separate channel directory? | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-46188@lists.php.net to get a copy of this message | ||
On 4/9/07, Pavel Shevaev <pacha.shevaev@gmail.com> wrote:
On 4/9/07, Brett Bieber <brett.bieber@gmail.com> wrote: On 4/9/07, Christian Weiske <cweiske@cweiske.de> wrote:Hooray for PEAR Channels! Many thanks to Greg Beaver for this.Paul,A good convention package maintainers should follow is to use unique package names for common utilities to avoid collisions (eg, Savant) or prefix the channel in the package name --- such as Chiara_PEAR_Server for pear.chiaraquartet.net or UNL_Templates for pear.unl.edu. Let me not agree with you. I'm a lead developer of the Limb Framework[1] and it doesn't actually use PEAR class naming conventions. Instead we simply prefix all our classes and global function with prefix "lmb": lmbActiveRecord, lmbDBAL, etc. Limb packages also don't follow PEAR naming conventions, e.g: "active_record", "dbal", etc. Since Limb has it's own PEAR channel[2] with "limb" alias and this alias is used as a root directory for all packages, Limb packages happilly live inside "limb/" include path without collision with other packages, e.g "require_once('limb/active_record/src/lmbActiveRecord.class.php')".can be conflicts. Why not put all these items into subdirectories named after package's channel name? However there can be an exception for system level package artifacts(PEAR itself).The docs for a package are installed into docs/packagename/. If a package has the same name and files like another package, it already conflicts at php file level.
However tests and documentation are not isolated from other packages with channel alias, hence the question. PEAR Installer is great stuff for packages distribution however it should not enforce its packages naming conventions everywhere IMHO.I see. I guess I'm just used to the standard placement for files with a role of doc as doc_dir/{Package_Name}/ --- that's where I would expect them to be. I haven't tried this, but have you looked into the install-as parameter? This may allow you to specify a different name & location for your docs. If the install-as parameter doesn't work, how about a custom file role with <honorsbaseinstall>1</honorsbaseinstall> ? You could easily set up a new role for your docs and install them in the doc_dir/{baseinstalldir}/ or wherever you like. -- -Brett Bieber http:saltybeagle.com aim:ianswerq