[grigori]

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.

[mindplay]

grigori, on 15 August 2011 - 09:30 PM, said:

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.

Agree - a module or component may require configuration, but a package would not.

A package should come with some sort of manifest though, as discussed - this probably shouldn't contain any functional configuration as such, though.

[Rodrigo Coelho]

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.

[mindplay]

mentel, on 01 September 2011 - 07:32 PM, said:

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.

[mindplay]

This looks interesting:

https://github.com/composer/composer

Might make a useful starting point?

[lubosdz]

If I understood correctly, packages in sense of redistributing the code should be capable of communicating with central package repository, right?

- search repo,
- find the package,
- check and display dependencies,
- download package,
- install package

CLI mode or HTTP (GUI) mode?
Perhaps separate module like Gii?

Looks like pretty big thing, uff.
But may bring the framework to completely new level of interaction during development - big step ahead.

Thumb up that you decided to keep modules - they are very powerful and useful.

Lubos

[samdark]

Correct. I'm working on cli mode first. Then will consider GUI.

[schmunk]

Hi samdark,

I've a question regarding cli vs. GUI.
As far as I can tell there's currently no other way to run console command from within a web application than exec?!

Do you plan to add a component which works as a link between web app and cli app?

I played around with exec, but the problem is, that you often have different values for yiic on different systems (Win, Mac, Linux).


Best regards,
schmunk

[jacmoe]

Are you looking for something like this? ->
http://www.yiiframew...ithout-a-shell/

[Antonio Ramirez]

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?

[samdark]

Yes, I think "extension development guide" will be helpful. Will consider writing it.

[dckurushin]

official packages would be good...
cause it is scary sometimes to use others extensions cause you cant be sure they 100% correct without bugs ...

[schmunk]

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?

[samdark]

schmunk
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.

[outrage]

Yii core is already pretty 'thin' compared to most other frameworks, with lazy loading too.

I would avoid adding complication where it's not necessary, or at least make the default download contain everything.

Never forget the newbies. A seasoned Yii user can trim where necessary.

[KEo]

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.

[Lukas Kahwe Smith]

for the package management have a look at composer and http://packagist.org/

[samdark]

Lukas
I've checked these about two months ago. Did't like:

1. Lack of simple end user docs.
2. Symfony2 dependencies.

but now, as I can see, everything is in a PHAR and there are some docs. Will check/try it again. Thanks.

[este]

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).

[samdark]

No, it is not about CMS-like plugins.