Re: [PEPr] +1 for RFC::Requiring E_STRICT Compatibility for New PEAR Packages

Dan Scott wrote: > Note: I'm responding to this outside of the formal voting conventions > because 1) I should have made this as a comment to the proposal, but > just became aware of the proposal this past weekend, and 2) until I > actually have a pepr of my own approved, I don't feel like my vote > should count. > > I can't help but think that Lukas has hit on something important with > his concerns about the implications of this proposal both for naming > and for the inevitable E_STRICT changes introduced in both y and z > releases of PHP x.y.z. > > I think overloading the package name to indicate both API breaks (e.g. > MDB vs. MDB2) and supported PHP versions is a mistake. Let's assume, > per the example in the RFC, that package Example_Foo is created for > PHP 5.1.4 E_STRICT compatibility, with Example_FooPHP4 for PHP 4 > usage. When PHP 6 comes out, does Example_Foo get renamed to > Example_FooPHP5 and a new package Example_Foo get released for PHP 6 > compatibilty? > > Of course, criticism without at least some alternatives (practical or > not) is unfair. So rather than making the package name do everything, > would it be possible to make PEAR's package management tools do more > to help manage things? The pear command knows which version of PHP is > invoking it and could theoretically search for the requested package > version that meets its intended needs from an =x.=y.<=z, x.<=y.*, > <x.*.* PHP version matching algorithm. (This, by the way, is how my > naming counterproposal also gets around the problem with new or > changing E_STRICT definitions that may be introduced by the core PHP > maintainers in future version bumps). > > For example: > > (running with PHP 5.2.0): # pear install MDB2 > ... searching for an MDB2 package specifying minimum PHP 5.2.0... > ... searching for an MDB2 package specifying minimum PHP 5.*... > ... searching for an MDB2 package specifying minimum PHP 4... Found! > Installing MDB2... > > Then, running pear upgrade could also note the currently installed > version of PHP and adjust accordingly (so if you were still running on > PHP 5.0.3 for some reason and upgraded to 5.2.0, pear could grab > updated versions of packages that specified PHP > 5.0.3 and >= 5.2.0). > > Next question: how are these separate versions of the packages > maintained and distributed? Well, we have channels now, and we have > branches in CVS. On the surface, at least, it seems like it would be > possible to have a pear-5.2 branch that matches a pear-5.2 channel, a > pear-5.1 branch that matches a pear-5.1 channel, etc... This has been proposed before, and is not a good solution for the same reason you say "Long_Package.." is a bad idea. Channels implement a kind of virtual namespacing of packages (i.e. a package with the same name can exist on separate channels) with the difference that they cannot co-exist if their files conflict. What you want is meta-data that allows the installer to only install packages that match a particular condition. The solution is instead to implement package groups on the server side (meta-data again) and make the installer smart enough to understand them. As soon as the mountain of work subsides, I may be able to finally implement this in pearweb. > PEAR also gives us the capability to identify package API version > dependencies in the package. It would be nice to be able to use these > to avoid having to munge the name (creating, say, MDB3). This is going to require a change to package.xml, and is not the best solution. What we really need is a solution similar to what Ruby uses in their gems, which is to say a fast class loader (native, not written in PHP) that can be used to allow different versions of the same package to co-exist and be loaded into PHP in the same process. This requires namespaces and a few other things in the core, so we'll have to see. Greg