Making local installations easier

Hi, All this wrangling over BC raised a good point that I think could be resolved easily enough: pear needs to support local installations better to allow users to have local copies of PEAR packages for local applications. Would there be any opposition to adding a new command specifically for local PEAR packages? This would have no affect on PECL, as PECL by nature must be a global installation. $ pear --local install $ pear --local list or perhaps a new command would be better: $ pearlocal list This would list only the local packages The user can still see system-wide packages by running $ pear list with the fix I just committed to CVS for locking issues. Basically, the local command would search by default ONLY in the ~ directory for .pearrc, or in windows, in UserDir (Documents and Settings/ in XP, other dirs in earlier OSes that I don't know off the top of my head, etc.). Someone with OS X would have to enlighten us as to whether ~ is the same as it is in linux. This way, we can take the first big step towards guaranteeing that users can resolve BC issues with the system-wide installation: they can quickly and easily install local copies of the packages they need with the lower version, giving them time to upgrade their app to use the newer version, or if they don't want to, they won't need to. The difference here between --local and existing --installroot is that --local is slightly more intuitive. --local would probably be implemented as a wrapper around --installroot with some code to check OS and specify the OS-specific ~ directory as the argument. I don't know how the web installer would be affected by this change, probably not much, since it's already quite versatile. Another change that would make sense is the ability to quickly and easily install a dependency into a subdirectory of a package. In other words, let's say phpDocumentor is installed, and depends on DB_NestedSet 1.x. On the release of DB_NestedSet 2.x, the user would be told they can't upgrade to 2.x, the 1.x API is required by PhpDocumentor. However, they can be told to run $ pear install-deps PhpDocumentor DB_NestedSet or $ pear --local install-deps PhpDocumentor DB_NestedSet (depending on where PhpDocumentor is installed) which would install DB_NestedSet into a subdirectory of PhpDocumentor, and adjust a single file in PhpDocumentor that includes DB_NestedSet, so that it instead includes the local copy. Then, the user would be free to upgrade DB_NestedSet with no adverse affect on PhpDocumentor. Then, when the next version of PhpDocumentor is released that depends on 2.x, the user can simply upgrade, and the old PhpDocumentor-specific copy of DB_NestedSet 1.x will be removed. This would not need to be a BC break within PEAR itself, as I think the option can only realistically be available if PhpDocumentor has a bit more information in the package.xml's <deps> section, but I don't think it would require much more information, just the name of a script to run that would modify the file if a local dependency install is needed. If that information isn't present, the upgrade would simply fail unless PhpDocumentor were uninstalled. This would imply that DB_NestedSet version 1.x only is allowed (as discussed in the earliest RFC) <dep type="pkg" rel="ge" version="1.6">DB_NestedSet</dep> Change it to: <dep type="pkg" rel="ge" version="1.6" localscript="PhpDocumentor/scripts/localinstall.php">DB_NestedSet</dep> Then, the script would be run by include "PhpDocumentor/scripts/localinstall.php"; or running a separate php process with the script (to prevent fatal errors killing the install) In this way, it might be unnecessary to rename anything for any reason (hence Alexey gets happy). For these reasons, I'd like to hold off on any voting on the BC RFC until the new ideas can be processed. Greg P.S. Just a friendly reminder to all: if you believe your idea is better than someone else's, you will not convince that other person that your idea is better by calling them names, denigrating their intelligence, or any other shenanigans. It seems obvious, but we all fall down on the job :). Back up your ideas with code, examples, and respect, or very bad decisions might be made, simply out of spite. I am guilty of some of this stupidness with unnecessarily personal comments like "totally bogus" and I apologize for that, specifically to Pierre-Alain and Alexey. If you don't have time, you can always say "I disagree with this, I don't think it is the best way, I will present my reasoning very soon, I don't have time right now" rather than "I see no reason for this" or "I am opposed to this." Then the flame wars disappear, and things get done rather than the usual path straight to the garbage pit. If you really like spectacular fireworks and fighting, you all should try being a professional string quartet musician, you'll get your fair share every day :)