Re: channels

Joe Stump wrote: > I've been playing with PEAR 1.4.0 (*waves to Greg*) and I've got a > small concern with the introduction of channels. Channels are going to > be awesome, but they also introduce a problem (in my not-so-humble > opinion). > > I've been working on a MVC framework that will be released via a PEAR > channel that has yet to be created. My package depends on > pearified.com's Smarty template package. This isn't the issue I have > though, the issue I have is that pearified's channel installs > everything into "Pearified/". I would think Smarty should go into > HTML/Template/Smarty or something like that. this would conflict with PEAR's HTML_Template_Smarty should that ever happen. As it stands, PEAR is the standard source of PEAR, and other channels must take steps to ensure that they do not conflict with each other. The best way to do this is to have a directory into which everything is installed. > Is this something that's being mandated by PEAR (channel packages must > go in $channelName/Package_Name)? It's not a huge issue I guess, but I not mandated, just recommended. If you are not going to distribute your packages globally (local channel for a customer, for instance), you may use any naming scheme you would like. > wonder if we're creating a monster with channels in this regard. No > longer will people have to follow CS, etc. They can just throw up their > own channel and start releasing whatever they want (a good thing) with > no oversight (a bad thing). I am fairly confident that as channels begin to emerge, there will be a more Adam Smith-ian oversight called market forces. In other words, channels with good code and docs will become infinitely more popular than channels with sucky code and docs. We will have to address this as the technology evolves. The whole point of channels it to put a little faith in developers and to provide a model with pear.php.net. So far, every channel I know is following the model and providing a higher quality alternative to the unzip-and-go model that prevails outside PEAR. > My concerns also include support issues. I'm willing to bet some of the > people who don't know much better will be asking for support from the > PEAR lists for packages released via other channels - "Well, I > installed it with PEAR". In marketroid speak this, I believe, is called > "diluting the brand". Not much that can be done about this. However, if they install it from an external site, this means they know about that external site. I would actually expect that more often we will find problems in PEAR being reported to the external site rather than the other way around. > Also, will the CS be updated to cover for cases where proposed PEAR > packages rely on packages from other channels? Is it appropriate for a > PEAR package to rely on a non-PEAR-channel package? PEAR packages can never depend on external channnels, this is a recipe for disaster, as you note. Greg