Re: not-yet-draft RFC on the new versioning standards for PEAR2 (needs PEAR Group sponsor to be official)

On Thu, 2010-01-07 at 08:18 -0600, Greg Beaver wrote: > Brett Bieber wrote: > > On Wed, Jan 6, 2010 at 11:35 PM, Michael Gauthier <mike@silverorange.com> wrote: > > > >> On Tue, 2009-12-29 at 14:11 -0600, Brett Bieber wrote: > >> > >>> I've added myself as a sponsor to this RFC and marked it as a draft. > >>> > >>> If anyone has any remaining comments on this proposal, please send them now. > >>> > >>> > >>> http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision > >>> > >>> > >> I had a bunch of feedback prepared for this RFC but then today on IRC, > >> Helgi, Brett and I uncovered a larger problem -- that of parallel > >> installability. > >> > >> Here's the problem: > >> > >> * Package-A depends on the API of HTTP_Request 1.x > >> * Package-B depends on the API of HTTP_Request 2.x > >> * User Alice wants to use both Package A and Package B in her > >> application. > Hi, > > Let's not forget that it is impossible to use 2 versions of the same > package because they will have the same class names. No amount of path > finagling can fix this, and it is an inherent problem. I also tend to > think that this scenario is exceedingly uncommon (using 2 versions of > the same package in the same PHP process). The main thing is that > per-request, we should have one version of a package in use at a time. > > However, if the question is regarding 2 independent applications, then > the solution is simple with Pyrus: create 2 separate installations, and > use my_pear_path to utilize dependencies from the main install so that > we only install HTTP_Request 2 in that install, and use include_path set > to the same value. > While it is impossible to use two versions as described in the RFC, it is possible to do so in PEAR(1). In PEAR(1), the package name and class names get suffixed with the major version number (HTTP_Request2, HTTP_Request2_Response, etc). This prevents file and classname collisions when a new API is released for a stable package. It is also not an uncommon problem in PEAR(1). For a year, Services_Amazon_S3 depended on HTTP_Request, Crypt_HMAC and Net_URL while Services_Amazon_SQS depended on HTTP_Request2, Crypt_HMAC2 and Net_URL2. It is quite reasonable for an end-user developer to want to install and use both SQS and S3 packages in the same application. Services_oEmbed is another good example. This one package depends on both Net_URL2 and Net_URL (through its HTTP_Request dependency). Using the proposed RFC, it would not be installable. There are about 15 packages depending on HTTP_Request2 and 30 depending on HTTP_Request. Any time you want to use a packages from both sets of dependencies in the same application, you run into this problem. For two independent applications, the problem is simple as you have described. Two separate local installations works well in that situation. Cheers, Mike