Re: PEAR2 wiki document

Travis Swicegood wrote: > On Aug 26, 2007, at 9:43 PM, Gregory Beaver wrote: >>> Assuming pear.example.com used Example as their namespace. Declaring >>> the namespace would then be a case of modifying channel.xml to include: >>> <name>pear.example.com</name> >>> <namespace>Example</namespace> >>> >>> Once it's discovered, nothing else could use the namespace Example >>> without displaying an error. If a server changed, that would display >>> an error as well. The namespace, which would be kept internally with >>> the channel name, would then just route everything the way an alias >>> does. It would also be the assumption that "pyrus install >>> Example::SomePackage" would be the equivalent in today's PEAR as "pear >>> install example/Example_SomePackage". Again, the assumption is made >>> that Example_SomePackage would be replaced with Example::SomePackage. >>> >>> I'm not sure I see any way to circumvent such a setup without having >>> access to change the internal config/registry files for a given PEAR >>> install. If someone who shouldn't have access to those managed to do >>> that and make changes, there's bigger issues at that point. >> The current system of <suggestedalias> is like your namespace tag, but >> allows the user to "import" a namespace through the "pear >> channel-alias" >> command and is in fact closer to the idealized namespace implementation >> than your proposal ;). Seriously though, I am not convinced there is a >> compelling reason to change this system to make it more restrictive. > > Ok - I'm trying to think up a way to remove some duplication. You > could install pear2/HTTP_Request, but then when that file is located > in PEAR2/HTTP/Request.php there's a disconnect to me. most likely, the default repository for pyrus will be pear2 - the section in the coding standards that talks about package names is not set in stone, we may in the end go with PEAR2:: or PEAR2_ prefix for all packages. I'm starting to lean in this direction for many reasons, the one you point out above being a significant one. >>> I think allfiles needs to be generated. As has been pointed out >>> several times, its easy enough to do programatically, so why add to >>> the developers troubles by making it a required check-in. I'll put >>> together one for phing... >> Sounds fine to me. I would prefer that the packager generate it if one >> doesn't already exist, or if requested. Phing as an option for >> packaging would be interesting to some folks (if you want to write it >> and maintain it). > > I would like to move the packager portion out of pyrus all together > (seems like we've had this discussion). Adopting something like phing > with an official build.xml template to work from adds a ton of > flexibility and moves part of the complexity of pyrus off to another > system. We won't officially be adopting support of Phing for creating packages, but welcome this as a third-party addition. Packaging will be completely separate from Pyrus, Pyrus is intended to be for installation only. The plan is to have a package, perhaps PEAR2_Developer (or PEAR2::Developer if we go that route) that will be needed in order to create packages. > > > >> This leads me to believe that perhaps class_exists() is not a solution, >> and the only solution that is both flexible and fast is the doc comment >> at the top of the file needs to document where to find required classes, >> and the coding standard should be updated to reflect this. > > I'm for this - with pyrus being able to scan for dependencies. Maybe > something along the lines of 'pyrus check Example::Package'. > > At any rate, I have a generic annotation parser that I would be happy > to contribute to PEAR2 to help get that going... I don't think we need to have this in pyrus, if a user installs a package using pyrus, it will automatically install the dependencies. This would only be for users who download a .zip or .tgz to try it out, to make their debugging lives easier. Greg