[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pear-general
Subject:    Re: [PEAR] Re: Use pear as installation library
From:       Gaetano Giunta <giunta.gaetano () gmail ! com>
Date:       2011-05-06 21:28:59
Message-ID: 4DC4681B.3000104 () gmail ! com
[Download RAW message or body]


Brett Bieber <brett.bieber@gmail.com> wrote on 06/05/2011 05:07:
> On Thu, May 5, 2011 at 5:22 PM, Gaetano Giunta <giunta.gaetano@gmail.com \
> <mailto:giunta.gaetano@gmail.com>> wrote: 
> On May 4, 2011, at 3:58 PM, Brett Bieber wrote:
> 
> On Tue, May 3, 2011 at 6:14 AM, Chen Xiongjie<chen.xcmail<at> gmail.com \
> <http://gmail.com>>  wrote: 
> Hi, pear
> 
> I'm looking for a php installation library so I can use it for install our \
> product's extension/plugin. Do you think is it good to use pear as the installation \
> library. 
> typically questions:
> - Does it support extendable tag
> - Is the API of pear open?
> - Any documentation for using pear API? (I just found this one but it's just a api \
> documentation:http://pear.php.net/manual/en/core.ppm.php) 
> - for long term, will it be a kind of formal/unformal php installer library?
> 
> I would use Pyrus if your application and extensions are PHP 5.3+.
> https://github.com/pear2/PEAR2_Pyrus
> 
> The API is very easy to use. Here's a simple autoloader example which installs a \
> package from a PEAR \
> channel:https://github.com/saltybeagle/AutoloadPackage/blob/master/AutoloadPackage.php
>  
> 
> The API is documented pretty well:
> http://pear.php.net/manual/en/pyrus.extending.installation.php
> 
> PEAR packages are the easiest way to distribute upgradeable libraries of code for \
> your application. 
> --  Brett Bieber
> 
> 
> Hello.
> 
> I'm working on the same project as Chen (the op), and can shed more light about our \
> specific needs. I also have some more specific questions: The requirements are:
> . being able to install a "php application", not a library. It needs to be \
> installed in a user-chosen directory if possible (so that many copies of the same \
> app are installable in parallel), with utter disregard of pear standard \
> installation directories 
> 
> Pyrus can handle this easy
> 
> . a web-based setup wizard should be run as soon as copying of files is done
> 
> 
> If you're using the pyrus API, you can execute whatever you'd like.

Any suggestion on the best way to start a browser to run a web-based wizard from a \
php script (on linux/win/mac/solaris at least )?

> . as an alternative to the above (or in a 2nd step), we could replace the current \
> web-based setup wizard with a pear-installer wizard (example of checks it currently \
> does: variables in php.ini, presence of imagemagick in the PATH, presence of php \
> extensions, proper write perms on some directories) 
> 
> Basic stuff can be checked prior to installation... whatever else can be done in \
> your post-install scripts.

About checking stuff prior to installation: imagine a client has installed version X \
of my app in some dir, but not the pear-packaged version (since there was  no \
pear-version at that time). Another client has installed version X via a pear \
package. Both want to install a plugin for the app, compatible with version X (but \
not X-1) How hard would it be to integrate this prerequisite check into the pear \
package of the plugin?

> . being able to install plugins for the original application (in a subdir of the \
> app home dir). Again, some php scripts might have to be run after copying them
> 
> 
> Ok.
> 
> . install updated versions of the app&  plugins. In both cases, preinstall&  \
> postinstall scripts might have to be run (sql code&  php scripts, the latter can be \
> used to wrap the former) 
> 
> Wrap the installer and make it do what you want.

If I have to wrap the installer in my code, I might as well keep our existing \
installer code and forego pear usage completely. Most of the benefit I expect from \
switching to pear is to allow users to run "pear install myapp" without having to \
download anything first...

> . have online repos to install app&  plugins
> 
> 
> PEAR channels can accommodate this
> 
> Using pyrus is not currently an option, as the app has to be compatible with php \
> 5.2. 
> 
> Well shoot. I would not recommend building anything against the PEAR (1) API unless \
> you need PHP 4 compatibility.
As I stated above, I'm interested in php 5.1 and 5.2 compatibility, not it php 4. If \
Pyrus cannot run with such versions of php, then bad luck, I'll go with the  PEAR \
API.
> 
> If we use pear as main packages repository system, we could also have to use our \
> pear channels to host plugins for older versions of the application, that are \
> currently deployed on php 5.1 
> What I have found so far in my exploration:
> . besides postinstall scripts, custom file roles&  file tasks can also be defined
> . the online documentation for those 3 hooks is a bit lacking, as only the xml for \
> defining them is described, not really how they work. I could not easily find any \
> tutorial nor example of project using those hooks; any would be welcome (eg. which \
> one of these 3 hooks to use for different cases?) 
> 
> Have you read the PEAR installer manifest? Real world examples do exist. For \
> example the role=man, role=dbschema, etc. Greg's channel has quite a few examples.
I'm  a bit more thick than you probably expect me to be.
Is this the channel you refer to: http://pear.chiaraquartet.net/ ?
> 
> This is an application, (not a library), with a post-install-script: \
> http://code.google.com/p/unl-event-publisher/ 
> . since we already have a custom packaging format, with semantics richer (afaict) \
> than the standard pear package.xml allows, a 1st integration step could be to \
> simply produce a valid pear package.xml file that allows the user to download our \
> custom-package and have the pear installer run the existing \
> custom-package-installation php code either as post-install script or custom role / \
> custom task. 
> 
> Sure.
> 
> This is not the best solution in the long run, but it would allow a very fast \
> integration of pear into the existing system. Any drawback or suggestion in this \
> regard? 
> Last but not least: I am also looking to implement a pear server on top of our \
> current app (primary goal being able to turn the current "forge" site for plugins \
> into a pear channel server). 
> 
> Easy with PEAR2_SimpleChannelServer or Pirum.
You are probably right , but ease is not the only driving factor at play here. I will \
continue trying to build a new pear server on top of our existing "app  server" until \
I hit a major roadblock. I will of course incorporate parts/ideas of those two \
servers where it makes sense to do so.
> 
> Here again, online docs are good but far from complete, as a lot of things are \
> described as "use pear command xxx" instead of describing the actual operations \
> undertaken by the pear installer in such case. 
> 
> The majority of PEAR "end users" are using the CLI, so you should expect the \
> documentation for internal APIs to be lacking. If you're gonna get into the  \
> internals of the installer, you should be reading source code, not necessarily \
> end-user docs.
True.
My complaint was more about the fact that PEAR is developed as a set of tools and not \
as a set of APIS and formats. What I want to do amounts more to reverse  engineering \
for an alternative implementation, that's why I'd prefer to have better documented \
formats than easy-to-read code.

Thanks for taking the time to answer
Gaetano

ps: shall I create a new thread with my findings (bugs/oddities) when trying to \
implement a new role, or maybe post in another ml, or directly in the bug tracker?



[prev in list] [next in list] [prev in thread] [next in thread]