[samdark]

This concept is very controversial so your input can help a lot.

atomic core
The idea is to keep Yii2 core small, fast and flexible moving things like zii widgets, webservices and even active record out of it. Things to keep are base ones like autoloading, events, routing or CLI support.

packages
A package is some amount of structured code following a standard, documentation and a meta-description file. That's where all non-core code goes. Package concept will allow to use Yii2 as an atomic micro-framework or as a full-blown solution like current Yii.

Meta file should include package name, version, author, brief description, a list of packages and their versions it depends on.

package manager
Package manager should be simple to use. When one tries to get a package, it should be able to automatically get all dependencies automatically. One should be able to add/remove any package at any time (of course, if it's not required by another one).

ability to store packages at third-party servers
Currently we have extensions and one of the problems is that it's time consuming to upload archives to Yii website when extension code is updated. Overall, it's less time consuming to keep your code in a single place such as GitHub or your own server. So package manager should be able to install packages from different locations.

package repository
Since it will be hard to find a right package it's a good idea to have a central repository. Same idea as current extensions but the difference is that one should only specify URL to the package meta file and Yii website will automatically update description, version number etc. from the package and provide a summary page. Another difference is that files will not be stored at Yii website.

official packages
Among with packages that are maintained by developers we can review and "approve" some packages. Ones with decent documentation and code. These will be marked as "officially approved". It will solve the problem with choosing a stable code to build production system on.

[andy_s]

Package manager is a nice idea when there are really many packages. Yii Framework doesn't look that huge to me to split it into packages and install them by demand. But I like the idea of the official packages. It would be very nice to have officially tested and approved extensions.

And from the other side, if we want to make Yii a really powerful and extensions-rich framework, we will need this package system. That's why now I'm tending to like this idea But creating & installing packages should be very easy, and probably a web based?

[jacmoe]

I really like this idea.
Package management built right into Yii would make it so much easier to manage packages, not only Yii official packages, but third-party packages as well. Especially third-party extensions.

Is it inspired by the Phundament2-derived work by Schmunk?

[Ben]

I like the package-manager approach a lot, at least for 3rdParty/ community provided packages. Especially the review/ approval idea, since I believe it will push contributors to provide higher quality extensions. I would push this even further by providing sort of continuous integration service. On receiving a new version:

• run static code analysis (coding conventions, API documentation depth, code complexity, nesting depth, ...)
  
• generate API reference
  
• run unit tests and measure code coverage

from all this, generate publicly visible rating with access to detailed information if requested. Ideally, this should happen automatically (say author creates a new tag in his repo, the server hosting that repo sends a notification. Yii site updates the package locally and starts the build).

Really loved to have something like this...

---

For the core, I'm not sure it would be such a good idea. After all, it adds complexity both for you as maintainer and for all users which probably only want to use a great framework. Having to search for components and plugging them together... I don't know. I prefer downloading a framework and being able to do all sorts of things with it (including especially WS and AR, but also widgets which I loved to be extended - different styles for CMenu is something I missed for example). Do you feel Yii has grown so fat? What do you hope to improve by separating the framework into smaller chunks?

[Antonio Ramirez]

I love the idea of packages... and having a central 'official' repository -code review here is highly important, will make deployment even easier but pushing a 'lite' version to the server and then to run once to install all its requirements.

About the core, maybe is a good idea to have pre-configured those packages that are considered now as part of it (AR,WS,Widgets, etc), so to allow programmers to reduce it if some of them are not required but not to search for them, when they were always there before.

[Vince.]

Regarding core - What ever you do do not require users to download several items to be able to have the framework that want to. Instead do what zend does, Ability to "select" the packages you want to be in the core framework and download that as an entire package. That way a user can select to have EVERYTHING or the minium required for his setup. I hate the fact that a framework has only small portion of the entire code base. That's why smaller frameworks like VORK do not get popularity it's just too complicated and too small.

[robregonm]

Thumbs up for all your proposals @samdark, nevertheless we need to be careful when re-developing the atomic-core, if the atomic core will be lazy-loading as Yii currently does, will be great, I like the idea of autoloading some elements and keep unloaded the classes I don't use.
And I love the package repository, I always wanted something like that... I've used somthing like that in Typo3 CMS, I think that CMS has one of the best Package Managers, so we can take some ideas from it.

Regards,

Ricardo

[Mike]

While i know that many people don't like it i'd like to remind you that PEAR comes with a complete package system plus installer. I'm not really an expert on it but as far as i know they solved pretty much everything samdark described above. So even if Yii does not use PEAR packages, it may be worth a look to learn some "do's and don'ts".

[samdark]

I think we still should distibute Yii as a whole. The difference will be that we'll be able to uninstall some parts using package manager. Well, probably "core only" package will be handy too.

andy_s
Web based package installer is probably a good idea. Still, it should be doubled by console application in order to be able to automate installing process via shell scripts.

jacmoe
To be honest, I've never reviewed Phundament2. Is there a package manager?

Ben
Good idea about automating quality checks.

robregonm
We'll keep using lazy loading in Yii2. There's no other way to make framework fast and feature-rich at the same time.

Can you post some links to Typo3 manuals/implementation etc.?

Mike
Yes, PEAR is quite similar.

[robregonm]

@samdark
The current Typo3 version uses an extension manager as is in these pages:
http://www.packtpub....ypo3-extensions
A glimpse: http://typo3.org/doc....0.0/view/1/10/
A screenshot: http://preview.typo3..._c445b180fa.png
Extensions repository: http://typo3.org/ext...ons/repository/

The new Typo3 v5.0 implements a slightly different way to manage the packages, it is based in a new PHP framework called FLOW3 (still in alpha):
http://flow3.typo3.o...packagemanager/

I think we can take some ideas from Typo3, It is a bit complex sometimes (it's being improved in v.5.0) but it implements cool features and ideas.

Best regards,

Ricardo

[jacmoe]

Schmunk released p3widgets here:
http://www.yiiframew...nsion/p3widgets
It is the start of a unified extension/module handling/installation/configuration framework.
Interesting idea.

It sounds very close to the idea of packages.

Although p3widgets currently is concerned with widgets, it is the general mechanism which is interesting.

[Ivica]

I like idea of packages and official packages that would be mature and heavy tested packages, so we can use them and be sure that they do not have security risks, and should be documented good and in proper format.
Additionally, maybe some official packages can be in incubation state, which mean that they are close to become official packages, but still not tested/stable enough.

[mindplay]

Packaging sounds like a good idea, and I like the idea of keeping the core framework package thin.

If one package === one namespace in Yii 2.0, then this would also make it possible to use pharchives, which would be neat - this would make it really easy to switch to a newer version of a package, and you can comfortably keep the old version of the package around, without storing/deploying (or checking in) hundreds (or even thousands) of individual files.

I like that idea a lot. Fewer files, less mess, easier switching between versions, faster deployment - good stuff.

[schmunk]

Hi guys,

I am very pleased to see this discussion going on


First, isn't it like a package is just a standardized extension format?
Does not matter if a package contains a component or a module ... whatever.

@samdark
I totally agree with all your points.
And yes, there's kind of a package manger in phundament, it's called p3admin.
Check this posting, it's also shown in the video.

It basically just looks for a migration directory in modules and executes the migrations for database setup via yiic.
I think there should also be a convention about where to store files, i.e. protected/data/<packageName>

Every package should also provide a default configuration, which can be easily merged with the application configuration.
Configuration handling is also an issue in Yii, a package should be able to register itself within the application.

Regarding a package manager and a repository, what's about an yiic wrapper for git commands or for the GitHub API?
Console-based is a must.
I also strongly vote for GitHub! I've just started using it and found zero disadvantages compared to GoogleCode and svn.
And the ability to share code on GitHub is awesome.

Compatibility is also a thing to think about. Thinking especially about different jQuery versions here
But also cross-dependencies between packages.


Best regards,
schmunk

[jacmoe]

BitBucket!
Mercurial!!



<sorry>

[mindplay]

I'd like to propose that every package have a GUID, as a means of uniquely identifying a particular version of a given package - this would be useful in the package manager, when walking the dependency graph.

The GUID should change with each major revision of a package, as an indication that it is no longer backwards compatible. Dependencies should be specified with GUID (as well as package name) so that users receive a warning if they're not using the right version of a dependency.

Note that while this eliminates "fighting" for a "package name", packages may still "fight" for a namespace, so that doesn't really address that problem. I think "package name" should be == root namespace of a package by convention, and the Yii site should maintain a namespace registry. When you enroll a package, you reserve the root namespace, so we avoid collisions.

Alternatively, we could use the Java-style convention where the vendor name is used as the root namespace, which virtually eliminates collisions - e.g. "mindplay\ImageManager" different from, say, "somebody\ImageManager". One problem with that idea, is that this is not a convention generally followed by the PHP community, so not much use when integrating a third-party library into a package.

Thoughts?

[samdark]

mindplay
Instead of GUID that's not too human friendly we can just use versions:

x.0.0 — Entirely new API.
1.x.0 — partially non BC.
1.0.x — BC changes.

Using vendor name in namespace can be a problem because of autoloader convention for namespace to follow file system. Namespace system at website can be a good solution.

[mindplay]

samdark, on 01 August 2011 - 09:24 AM, said:

Using vendor name in namespace can be a problem because of autoloader convention for namespace to follow file system.

Not an argument for GUID, but why would that be a problem? Presumably, the autoloader will allow you to point a root-namespace to a particular folder - that's a basic feature of any modern autoloader?

All the Yii packages will likely reside in namespaces under "Yii", so Yii itself already follows that convention.

[mindplay]

mindplay, on 01 August 2011 - 07:19 AM, said:

Alternatively, we could use the Java-style convention where the vendor name is used as the root namespace, which virtually eliminates collisions - e.g. "mindplay\ImageManager" different from, say, "somebody\ImageManager".

SPL is about to standardize on this convention - I think we should consider following that standard.

[mindplay]

I will add that this namespace strategy works well when you adopt the idea of using a "vendors" folder - since all of your own libraries can go into one root namespace, you only need to configure the path to that root-folder of your namespace once.

For example:

• vendors/Mindplay/Annotations
  
• vendors/Mindplay/ImageManager
  
• etc.

Just one namespace => path mapping to configure, which makes it easy to install and configure third-party packages with many dependencies on other packages from the same third-party vendor.

Also, package managers need only know where the root "vendors" folder is located - they will then be able to automatically install packages and dependencies, without prompting you for paths to each individual package.

And finally, this eliminates "fighting" for package-names, since the full package-name is disambiguated by the vendor namespace-prefix.

In my opinion, this would work very well.