Re: real-world example of (smart) developers using PEAR without installation

Alexey Borzov wrote: > Hi, > > Greg Beaver wrote: >> This thread: >> >> >> http://www.nabble.com/phpunit-task%3A-using-PEAR_Config-and-PEAR_Registry-tf4383525.html >> >> >> was brought to my attention as an example of real-world developers using >> PEAR packages without a PEAR installation. I am not advocating that we >> provide support for third-party solutions, but the changes I'm >> suggesting would make it easier for them to solve problems that we have >> not anticipated without them having to bother us in any way, and also >> would not force them to choose, as at a certain future point, Pyrus >> could be used to upgrade without having had installed the packages in >> the first place. > > Greg, I'd like once again to point out that this makes sense for > applications (and the developer in question mentions phpunit, phpdoc, > phing, selenium) but far less sense for libraries (OK, phpunit may be > considered a library, though, but it doesn't have required dependencies > on other libraries). > > I'd like to suggest a mental exercise. Here is a package from current PEAR: > http://pear.php.net/package/DB_DataObject_FormBuilder/ > > Now let's consider a hypothetical developer who downloads the > hypothetical PEAR2_DB2_Dataobject2_FormBuilder2 without using the Pyrus > installer. Please outline the steps he will need to perform before he is > actually able to use said package. Hi Alexey, This is a great way to explore the problem the new system introduces and how it could be solved. First, I would like to back up and ask why this hypothetical developer would be using a PEAR2 package without having it installed. There are two use cases that I have seen in the real world: 1) trying out a package 2) bundling a package within another application with its own source repository. For user #1, a package of just the PEAR2_DB_DataObject_FormBuilder (I doubt we'll need more than the 2 in PEAR2) would not be super useful. They would need to download each and every dependency, and to figure this out somehow. This user would instead want a download that contains bundled latest releases of each dependency. This could be done automatically at package time, or a separate bundle could be automatically created at upload using package.xml 2.0's bundle feature. The advantage of bundling dependencies inside the release is you have 1 download, it's simple to see what to get. The disadvantage is that it increases the download time and package size needlessly for those using pyrus, which would ignore the bundled dependencies (they wouldn't be in package.xml). For user #2, again it would be a bit annoying to download each dependency, but I suspect the user could be enticed into using the pyrus installer to manage the installation if we provide a special "no registry" option. As package.xml is now a part of the registry (and is named in the special format package-channel-PackageName-version.xml or something similar to that, I'm not quoting source code, but am remembering what I coded last April), and so it is possible to "upgrade" an extracted package without needing it to be registered, as the registry could be constructed on the fly from the package-*.xml in the php_dir. Still, the installation would need to work without having the guys of pyrus - the registry and configuration file - present, which essentially makes it the same as unzip-and-go. I think it's important to note that the new svn.pear.php.net server will allow these folks to also take advantage of svn:externals as a solution to #2, although package version replacements would not be present, making svn:externals less useful (package version replacements are done at packaging time), although there are probably some weird svn properties tricks that could approximate the replacements that I am not aware of yet. However, I suspect that more users needing unzip-and-go will be trying out simple packages, and simply recommending that users try the pyrus installer (which will not need to be installed in order to work) for any complex scenario will help immensely. My goal - and this may not be clear - is to open up the net we use to snare users, and to hook more people into using Pyrus comfortably. I recommend the party line if anyone is having trouble managing an unzip-and-go is "use the Pyrus installer" Also, these thoughts are very new, so I would love to know angles or solutions I haven't considered or other potholes to navigate. Thanks, Greg