Atomic core and packages
Posted 18 July 2011 - 03:02 PM
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.
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 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.
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.
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.
Posted 18 July 2011 - 04:34 PM
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?
Posted 18 July 2011 - 04:40 PM
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?
Posted 18 July 2011 - 05:11 PM
- 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?
Posted 18 July 2011 - 06:16 PM
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.
Posted 18 July 2011 - 07:05 PM
Posted 18 July 2011 - 08:01 PM
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.
Posted 19 July 2011 - 01:54 AM
Posted 19 July 2011 - 04:59 AM
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.
To be honest, I've never reviewed Phundament2. Is there a package manager?
Good idea about automating quality checks.
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.?
Yes, PEAR is quite similar.
Posted 19 July 2011 - 08:49 AM
The current Typo3 version uses an extension manager as is in these pages:
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):
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.
Posted 19 July 2011 - 09:37 AM
It is the start of a unified extension/module handling/installation/configuration framework.
It sounds very close to the idea of packages.
Although p3widgets currently is concerned with widgets, it is the general mechanism which is interesting.
Posted 21 July 2011 - 07:43 AM
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.
Posted 21 July 2011 - 01:47 PM
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.
Posted 28 July 2011 - 04:43 PM
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.
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.
Posted 01 August 2011 - 07:19 AM
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.
Posted 01 August 2011 - 09:24 AM
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.
Posted 01 August 2011 - 12:20 PM
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.
Posted 12 August 2011 - 01:42 PM
SPL is about to standardize on this convention - I think we should consider following that standard.
Posted 13 August 2011 - 09:03 AM
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.