View Source

<ol>
<li><ac:link ac:anchor="distribution"><ac:link-body>Module Distribution</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="installation"><ac:link-body>Module Installation</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="upgrades"><ac:link-body>Module Upgrades</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="fetch-install"><ac:link-body>Module Fetch+Install</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="remove-downgrade"><ac:link-body>Module Removal and Downgrades</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="other-considerations"><ac:link-body>Other Considerations</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="community-pyrus-channel"><ac:link-body>Community Pyrus Channel</ac:link-body></ac:link></li>
</ol>


<p><ac:macro ac:name="anchor"><ac:default-parameter>distribution</ac:default-parameter></ac:macro></p>
<h2>Module Distribution (Fetching from distribution sources)</h2>

<p>The first step for installing a module is of course, fetching the module code from the distribution source and placing it in the desired location. This process can always be done manually, and does not involve triggering any sort of installation methods on the module being fetched. Locations from which modules may be fetched could include: a Git repository, a Pyrus channel, HTTP/FTP/SFTP, a local path, etc. A CLI wrapper could be provided for the task of fetching modules from common sources. By default, this command might fetch a module into the directory the command is ran from; but we could also allow an optional destination parameter to be specified.</p>

<h3>Pyrus repository</h3>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module fetch FooModule]]></ac:plain-text-body></ac:macro>
<p>This will acquire FooModule from the default configured Pyrus repository. Users would be able to easily add additional third-party Pyrus channels. In the case that multiple repositories are configured and the primary repository does not contain the package, it should proceed to check the third part repositories in the same manner as Linux package managers (yum, apt, pacman, etc).</p>

<h3>Git</h3>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module fetch git://github.com/JaneDoe/FooModule.git]]></ac:plain-text-body></ac:macro>
<p>This method would require Git to be installed. This will clone FooModule, and check out either the latest tag, or the master branch if no tags are available. If no tags are available, we may want to emit a warning that they'll be running off of master. Alternatively, a branch or tag could be specified:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module fetch git://github.com/JaneDoe/FooModule.git -b v1.2.1]]></ac:plain-text-body></ac:macro>
<p>This is basically a wrapper to `git clone`</p>

<h3>HTTP</h3>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module fetch http://somesite/modules/FooModule.phar]]></ac:plain-text-body></ac:macro>
<p>This will download the phar archive (module) into the current directory. A destination path could also be specified last. This is basically wrapper to wget/curl.</p>

<h3>Local</h3>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module fetch /path/to/local/module]]></ac:plain-text-body></ac:macro>
<p>This will copy the module from a local directory to the current directory. A destination path could also be specified. This is basically a wrapper to `cp -R`</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>installation</ac:default-parameter></ac:macro></p>
<h2>Module Installation</h2>

<p>Many modules may need to ensure that certain things such as a db connection is configured and schema installed, or perhaps that some public assets are copied into the application's plublic directory (or web server aliases, symlinks, etc are in place). This installation process would be triggered via the CLI:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module init ./modules/MyModule]]></ac:plain-text-body></ac:macro>

<p>If the module is &quot;installable&quot; and has not yet been installed for this application, we would run the MyModule\Module::install() method. The `zf module init` method assumes that a module has already been fetched from the distribution source and resides locally.</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>upgrades</ac:default-parameter></ac:macro></p>
<h2>Module Upgrades</h2>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module upgrade ./modules/MyModule]]></ac:plain-text-body></ac:macro>
<p>This would trigger MyModule\Module::upgrade(). First, it may also check the original distribution source (such as Git, Pyrus, etc) for updates if it retains such information somehow.</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>fetch-install</ac:default-parameter></ac:macro></p>
<h2>Module Fetch+Install</h2>
<p>Most typically, people will not want to fetch and install modules in two separate commands. We could provide a simple wrapper that would trigger both:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf module install FooModule]]></ac:plain-text-body></ac:macro>

<p>This would first fetch, then install the module (if required).</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>remove-downgrade</ac:default-parameter></ac:macro></p>
<h2>Module Removal and Downgrades</h2>
<p>If a module is not &quot;installable&quot; then a simple directory removal would be sufficient. In all other cases there should be a MyModule\Module::remove($keepConfig) method that, if the user wishes, can keep the configuration present. The install() method would have to check for existing configuration and be sure merge or skip replacing the configuration files should the user decide to install the module again. (Added via <ac:link><ri:user ri:username="spiffyjr" /></ac:link>'s comment.)</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>other-considerations</ac:default-parameter></ac:macro></p>
<h2>Other Considerations</h2>
<p>If the user is already cd'd into a module's directory, commands like `zf module upgrade` could be ran without the name or path to the module.</p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>community-pyrus-channel</ac:default-parameter></ac:macro></p>
<h2>Community Pyrus Channel</h2>
<p>It is proposed that we have an &quot;official&quot; Zend Framework module Pyrus channel. This channel should be the default configured channel that is searched when `zf install FooModule` is ran. Additionally, there should be a way to easily publish modules to this repository via the command line. This idea comes from node.js's NPM package manager:</p>

<h3>CLI Pyrus Channel Publishing</h3>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf channel register janedoe@domain.tld
Choose a password:
Confirm password:]]></ac:plain-text-body></ac:macro>

<p>This would utilize SSL by default. Upon successful registration, it would store the credentials in a config file somewhere.</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[prompt> zf channel publish ./modules/MyModule]]></ac:plain-text-body></ac:macro>

<p>Meta-data could be pulled from the Module class, with certain fields being required.</p>