 | To avoid missunderstandings This component is intended for use by ZF applications to enable them to support loading extensions or plugins within themselves. |
Zend Framework: Zend_PackageManager Component Proposal
| Proposed Component Name | Zend_PackageManager |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_PackageManager |
| Proposers | Ben Scholzen |
| Zend Liaison | TBD |
| Revision | 1.0 - 25 April 2009: Initial Draft. (wiki revision: 6) |
Table of Contents
1. Overview
Zend_PackageManager is a component similar to package managers of different linux distributions, like for example apt-get. Consider an application which you would like to spread, like a blog software. You will most certainly want to give the user automatic upgrade-possibilites, or simply giving him a facility where he can install and upgade plugins.
Here comes Zend_PackageManager into the game. It allows you to search for packages in an application-specific repository and install packages contained in it. Zend_PackageManager will take take about depency packages and install them as well, if not already installed.
When installing a package, an install-script in it will be executed which then sets up chmod rights, creates database tables and so on. When upgrading from an older package a newer version, the required update-scripts will be executed.
A depency package may be a JavaScript library like jQuery for example, or an icon package, or a special filter and so on.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will allow to install and update packages.
- This component will do depency checking on install and upgrading.
- This component will also check depencies of other packages when updates of new depencies is required.
- This component will allow repositories placed in the local filesystem, HTTP(S) and FTP.
- This component will allow automatically installed packages (depencies) which are no longer required.
- This component will include Zend_ProgressBar support for installation routines.
- This component must define a repository structure which user has to follow.
- This component must allow caching of meta-information.
4. Dependencies on Other Framework Components
- Zend_Exception
- Zend_Filter_Decompress
- Zend_ProgressBar (optional)
5. Theory of Operation
The component is instantiated within a repository URL. It will then download a head file containing all packages with their meta-information. The user can then search through the package list, get information about them and display them to the user.
When packages are choosed for installation, the component downloads those packages and all required depency packages. When there is a conflict, the user will be informed about that via an exception. After the packages were downloaded, they are going to be installed.
In this process, the files in a package are placed in their desired locations, and then an optional install- or update-script shipping with it will be executed. When the installation was successful, the install/update method will simply return true.
6. Milestones / Tasks
- Milestone 1: Working prototype checked into the incubator
- Milestone 2: Unit tests exist, work, and are checked into SVN.
- Milestone 3: Initial documentation exists.
7. Class Index
- Zend_PackageManager
- Zend_PackageManager_Exception
- Zend_PackageManager_Package
- Zend_PackageManager_PackageList
- (more will follow when creating the prototype)
8. Use Cases
| UC-01 |
|---|
| UC-02 |
|---|
| UC-03 |
|---|
9. Class Skeletons
Skeletons will follow ...
10 Comments
comments.show.hideApr 25, 2009
Robin Skoglund
This proposal is interesting, and my initial response is "yes, this is something I'd like to see in ZF", but it doesn't reveal much information on how the component works behind the scenes. I don't feel that I have sufficient knowledge to actually review the proposal, so are you sure it's ready for review?
Frontend/backend system
I assume the intention is that Zend_PackageManager is the backend part of a typical package manager, which would support multiple frontends (mainly CLI and web). This begs the question of how the backend would bind to a frontend:
Regarding actions and other methods
The proposal should make the distinction between ordinary package manager actions (install, update, upgrade, etc), and supporting auxillary methods (set repository URL, etc). This goes for both the PackageManager class and the Package class.
Perhaps the actions should be delegated to separate task classes (InstallTask, DownloadTask, etc). Besides making the API clearer, this would make it easier to extend and write custom tasks, and would allow for nice implementations of the Command pattern.
...
I could go on and on about discussing this component, but I've said enough for now. I hope for a fruitful discussion in the proposal, and I'd love to see this component implemented in a clean and extensible fashion.
PS: find() should be renamed to search(), to better resemble the lunix package managers the proposal is referring to
Apr 25, 2009
Benjamin Eberlei
erm? ever heard of PEAR? and Pyrus? there are several years of experience in this and its shaping up very good. what makes you think this can do better?
Apr 25, 2009
Ben Scholzen
Well PEAR is written in PHP4, thus it could throw strict warnings / notices. Didn't know about PEAR2_Pyrus yet, after reading a bit on it, it may actually do the (same) job.
Tho, many features comming from components existing in ZF are also available in components of PEAR, so is that a reason to drop them? E.g, there is a Whois-component in PEAR, should I shop writing ZendX_Whois now?
Apr 25, 2009
Robin Skoglund
It's okay if it's a significant improvement of the PEAR alternative, I think.
Apr 29, 2009
Timo Ziemann
+1
I already thought of something similar..
May 09, 2009
Till Klampaeckel
Please do not re-invent the wheel. If there's anything missing in pyrus, just ping the developers and work with them.
http://wiki.pear.php.net/
Jul 10, 2009
Sébastien Cramatte
I've just announced a similar project on google code. http://code.google.com/p/concentre-packages-manager/
I will be happy to give an hand on this proposal and fusion our both projects and ideas.
Cheers !
Aug 02, 2009
fc
This component is essential to the ZF project. I honestly don't want to use PEAR or Pyros to manage ZF packages. I don't think ZF should depend on external tools. I don't think the idea is to port Pyrus, but to build a simple package manager for this project.
+1
Aug 12, 2009
Andrea Turso
In my opinion creating a package manager is no "reinventing the wheel", as Till Klampaeckel said.
For instance try to adapt PEAR (or other similar tools) to manage Zf packages, or for example the packages of a given web application.
I think there are many use-cases where this component might be really useful.
There is the growing trend – I have no data to support, it's just a personal assumption – of shipping a package manager within web applications to manage additional features like plugins, modules and translations.
So, I vote for this proposal. +1
Feb 06, 2011
Dolf Schimmel (Freeaqingme)
Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.