Why doesn't PEAR install package docs, tests into separate channel directory?

Hi folks!

I wonder why PEAR installer doesn't install package docs,
tests into
separate channel directory?

For example, package docs are installed into PEAR/docs
directory and
since not all channels follow PEAR namespace naming
conventions there
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).

So instead of this:

docs
`-PEAR
`-Foo_Bar
...

It will be something like this:

docs
`-PEAR
`-foo
  `-Foo_Bar
..

-- 
Best regards, Pavel

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Paul,

> 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. If the conflict is only at doc
files level,
the package should be fixed. If people don't follow
standards, there are
always situations in which things collide.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

On 4/9/07, Christian Weiske <cweiskecweiske.de> wrote:
> Paul,
>
> > 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.

I agree with Christian here. Not to compare PEAR packages to
.deb or
.rpm package files, but if you get a lib from one place with
the same
named files - of course they will collide with each other
and one will
overwrite the other when you install.

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.

-- 
-Brett Bieber

http:saltybeagle.com aim:ianswerq

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 4/9/07, Brett Bieber <brett.biebergmail.com> wrote:
> On 4/9/07, Christian Weiske <cweiskecweiske.de> wrote:
> > Paul,
> >
> > > 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.
> 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.c
lass.php')".

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.

[1] http://limb-project.com
[2] http://pear.limb-project
.com
-- 
Best regards, Pavel

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 4/9/07, Pavel Shevaev <pacha.shevaevgmail.com> wrote:
> On 4/9/07, Brett Bieber <brett.biebergmail.com> wrote:
> > On 4/9/07, Christian Weiske <cweiskecweiske.de> wrote:
> > > Paul,
> > >
> > > > 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.
> > 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.c
lass.php')".

Hooray for PEAR Channels! Many thanks to Greg Beaver for
this.

> 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//   --- 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//  or wherever you like.

-- 
-Brett Bieber

http:saltybeagle.com aim:ianswerq

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php