Re: [PEAR2 CS] Channel in paths

Hi, 2011/9/13 Васил Рангелов <boen.robot@gmail.com>: >> -----Original Message----- >> From: Brett Bieber [mailto:brett.bieber@gmail.com] >> Sent: Tuesday, September 13, 2011 4:38 PM >> To: Васил Рангелов >> Cc: pear-dev@lists.php.net >> Subject: Re: [PEAR-DEV] [PEAR2 CS] Channel in paths >> >> 2011/9/13 Васил Рангелов <boen.robot@gmail.com>: >>> When using the Pyrus make command and installing the resulting >>> package, I noticed that my test and doc files end up within a channel >>> directory and only then with the package name. The PEAR2 coding >>> standards talk only about data files. >>> >>> I'm assuming this part is meant to apply for test and doc files too, >>> but regardless, I want to ask what is the rationale behind that? >> >> This is used to namespace the data/docs/test files, and ensure they don't >> collide. >> >> PHP files already have this from the PHP Standards Working Group & >> PSR-0 naming standards which encourage a vendor namespace prefix for class >> names. >> >> For data files, there are currently no standards besides what Pyrus is >> trying to do. If one were to just use the package name, there are so many DB >> packages out there you'd immediately run into conflicts with filenames. >> You're correct that the PEAR2 packages would not collide, but nothing in the >> PEAR installation infrastructure requires a vendor prefix on package names >> (PEAR(1) for example has no vendor prefixes). >> >> There could be some debate over whether packages should know which channels >> they're distributed on, but in practice this rarely changes. >> The best way to handle this within your PHP files is to add a helper method >> to retrieve the data_dir. Check once if you're running from a vcs >> clone/checkout or installed with a pyrus controlled registry. >> >> -- >> Brett Bieber > But that's just it... PEAR1 has no vendor prefixes, while PEAR2 has one => > There's no collision between PEAR2 and PEAR1. Well, the goal for the Pyrus installer is not to be just for PEAR and PEAR2, but for all the PEAR-compatible channels out there. > All packages before PEAR2 were designed with PEAR1 in mind (that is, not to > be in conflict with known PEAR1 packages) => There are no collisions between > PEAR1 and 3rd parties. This is incorrect, PHPUnit for example, as well as pecl packages. This happens both when packages move from one channel to another, or are replaced by others. > I can see how there may be collisions between different 3rd parties, but 3rd > party packages either. > 1) use "pear.php.net" as their channel - In this case the collision with > other 3rd parties is not avoided by adding a channel folder. Correct, PEAR requires packages on pear.php.net be unique - so they will not conflict with each other, but could conflict with packages distributed elsewhere. > 2) use their own channel while still following the PEAR1 naming convention > to avoid conflicts with PEAR1 (e.g. PHPUnit, everything on pearhub) - in > this case the collisions between 3rd parties in the PHP folder are not > avoided, so even though the conflict in the other folders is resolved, the > conflicting package won't install anyway. Keep in mind, there's no requirement to use PEAR coding standards for packages on other channels. > 3) use a vendor prefix for their package name and folder structure (e.g. > Zend framework) - in this case all conflicts are avoided regardless of > channel > => a channel folder doesn't help to resolve any conflicts. Vendor prefixes for code is an obvious requirement, because you cannot use two classes with the same namespace and class name, BUT there is no such requirement for other files like docs, tests, data etc. > "If one were to just use the package name, there are so many DB packages out > there you'd immediately run into conflicts with filenames. " > Example? (googling "PEAR DB" only leads me to results about the DB package) Well, with tools like Pirum and SimpleChannelServer, PEAR channels have been popping up all over the place. I started a PEAR channel information aggregator a while ago to support the search command within pyrus, and so I can provide you with a few examples: These packages use the same name, but are distributed from different channels: Yaml, Config, Gearman, Zend, PHPUnit, Translator, Routing, Autoload, REST_Client etc etc. And, this does not account for all the PEAR packages distributed through the __uri pseudo-channel. -- Brett Bieber