The idea of packages is very good, with the right implementation.
If it has grown too large? Yes, it has, most of users do not know all classes and features it provides.
A core package is good. There are many projects like crawlers or daemons where I don’t have any web or something, but I would use the CComponent and like.
PEAR is close to death. It has a complex configuration managed by console commands, and can’t live without it due to its complexity. It has a rigid structure as well. Check it to avoid its problems please.
The packages subject is related to the namespaces discussion. Do you plan to separate packages to their own namespaces?
I don’t belive a package should have a configuration. Packages are not modules, they are plug-ins that you extract to the source, declare in main.php and use its API in your code.
I don’t see a reason to separate the core, but the package manager for third-party extensions is a great idea.
I may be missing something on the discussion about configuration, but my two cents:
I believe that every packaged item (extension, module, component etc) should provide its configuration (at least the default one) to be added by the package manager to the application’s configuration file(s).
There could be hooks for package installation and uninstallation, too.
Using these hooks, the packaged item will be able to automatically install itself to the filesystem and to the database.
The package metadata (meta file) could have also the version(s) of the framework for wich it is compatible.
If the framework core itself is distributed as a package with a metadata file, like any other package, a package manager would be able to check/update the core itself, the same way any other package is checked/updated.
It would be useful if the package repository provides a compatibility matrix based on feedback from developers, and this should of course take version numbers into account - when package X defines a dependency, it should specify the version number of the dependent package Y it was tested with, but when that dependent package Y receives an upgrade, you don’t know for certain if package X is forward compatible with those changes. The package manager can build a compatibility matrix by collecting this information from developers.
Another useful feature would be to provide a release-date in the package metadata - that way, you can put up a candidate release package, for example two weeks before it’s official release date. It’s a simple communication tool: the vendor has indicated that the release may be superseded by another RC within those two weeks - and the consumer understands that they’re using a brand new release which has not yet been widely tested.
One last thought: let’s have a web-based package manager interface. Of course, it needs to be accessible from the command-line, for automation purposes, but a web-interface could have a richer user interface - for example, it could collect and display information from the compatibility matrix, render a dependency graph, etc.
I really like the idea of being able to search/install packages but I believe that they should follow a pattern. What is the idea? that packages should incorporate a set of methods for them to be able to be search/installed/removed? How this pattern should be set? I think it is important: naming conventions, etc…
At the moment, Yii flexibility allows to create anything and plug it into the system by just set its alias/pàth and import them automatically when required. Any ideas on how those packages should be coded?
This could be a great feature, but nobody has talked about its format… ideas to work with package manager?
By following a pattern we could ensure the creation of top quality extensions… dont you agree?
Besides the source code (naming conventions, path imports, etc…) packages should take care about the database schema needed for the package via migrations and also about preparing local directories for storing files, if they have to do so.
Moreover they should provide a default configuration, often the main application configuration is affected by an extension (such as setting params, loginUrl, etc.). This is another thing to think about … can we simply merge any package configuration with the application configuration or do we have to implement boundaries?
Depends on what’s inside the package. If it’s a module then yes, most of your proposals are looking good but if it’s a widget then there’s no need to configure anything. I guess we’ll just write a guide on extensions to encourage best practice.
I think it is worth to consider handling multiple package repositories? I mean something like maven repositories - besides one official repository one can define 3th party repository or local user repository ($HOME/.yii-repo??).
Going further with maven spirit building and installing packages into repository would be also great feature - putting common reusable extensions development into separate projects seems reasonable for large teams.
I also agree with db migrations support on package level. There should be possible adding optional information of migration objects existence, thus installing package can do necessary database schema modifications easily. I can even treat this as "must-have" feature.
is there any practical or theorical difference between package and plugin?
maybe it is a bit stupid because i do not know many examples you mentioned… but could the Wordpress plugin system be somehow interesting as a reference?
the idea is that you can download a plugin from the Wordpress site, from the author site or install it directly from Wp admin area + eventually configure it (plugin developers can add an admin page to configure the plugin).
