The zfdevteam account on twitter just received the following question:
is it too hard to put a simple download zip as easy download?
The short answer: Yes.
The long answer follows.
First, with the release of version 3, there’s a question of what the download would include. One of the huge pushes with version 3 was to de-couple the various components so that they can work better standalone, extending this concept even to the MVC framework. The skeleton application currently only requires the skeleton installer (the piece that prompts you for which additional packages to install), the component installer (which does auto-wiring to ensure components and modules are registered with your application), development mode (which allows you to switch in and out of development mode), and zend-mvc itself. zend-mvc only depends on seven other components. This means that a minimal install has as few as 10 components! Depending on how you answer the installer questions, you may end up with 1 to 2 dozen more — but it’s still far from the entire framework!
The “zendframework/zendframework” package itself is not what it once was. Instead, it is a metapackage; it requires 60 of our components, mostly those that existed pre-3.0 or which provide functionality from pre-3.0, but once installed, it essentially disappears, and composer will list the other installed packages specifically instead.
Considering that it is a metapackage, and uses semantic constraints, that also means that any given install using the same version can pick up different component versions that fall within the listed semantic versioning constraints. So this also poses another problem: how would we version any such ZIP in the first place? What version would you have on download? How and when would you upgrade?
So, knowing this, what would a ZIP contain? The skeleton application? If so, with what options installed? The framework? If so, how would you go about setting up autoloading for the components therein?
Finally, putting on my maintainer hat, I have to ask something rather pointed: what use cases would you put it to, considering you’re likely only going to use either a handful of components, or would need to install the skeleton anyways in order to use the MVC? Why is Composer necessarily harder?
These are all non-trivial questions.
Composer has existed since 2011, is battle-tested, and solves all of these problems. It allows us to let developers pick and choose exactly which components they wish to use, with the specific versions they are interested in. It allows us to build installers that let you, the developer, choose the features you need for your application. It provides autoloading of all components for you. It allows you to see the unique set of package versions in your application, and version that via a lockfile in your application, ensuring your application works consistently across environments.
So, yes, it’s too hard to provide a “simple download zip”, because it’s anything but simple. Composer manages this complexity for both us and you.
2 Likes
ZF-build date could be used as version.
Periodically, manually. Same as we are forced to do anyway on shared hostings with no Composer available.
The same what the current metapackage contains after installing via Composer.
Before version 2.5, it was possible to use the same ZF copy for multiple applications, and store it once in one place, without having a separate copy for each application, and that was quite handy. Now we’re forced to install ZF metapackage and use Composer for this purpose, though could just download a single ZF archive.
I suspect the real issue that prevents entire ZF from being available for download is that ZF now depends on third-party packages and is therefore not standalone anymore.
This is still possible, in a couple of ways.
First, you can share the composer.json and composer.lock file between applications, assuming the dependencies are the same.
Alternately, create a metapackage of your own, pinning to specific versions of packages you use in your application. As an example:
{
"name": "your-vendor-namespace/zendframework",
"require": {
"zendframework/zend-mvc": "3.1.0",
"zendframework/zend-config": "2.6.0",
"zendframework/zend-escaper": "2.5.2",
"etc."
}
}
You would then require that particular package in your applications that share similar dependencies. This has an advantage for you over the ZF metapackage: the ZF metapackage pins to semantic constraints (which is why the answer to “what would a ZIP contain?” is not “what the current metapackage contains after installing”, as that may differ from day to day as new versions of packages it references are released), vs the specific version constraints you would have in this package.
We do not use specific version constraints in the ZF metapackage because we want folks to be able to update dependencies as new releases are made; having pinned dependencies means we would need to do a new release of the metapackage every time a new component is released, which is, frankly, untenable, and one of the reasons for the change.
Additionally, doing so leads to a number of problems when you want the bugfixes or security fixes in one package, but a change in another package might be unwanted or even cause issues in your codebase. With the current setup, a user can require the zendframework metapackage, and then pin to specific versions of components so long as they fall within the constraints of the metapackage. Pinning to specific versions would not allow this; it would be all or nothing.
The change in packaging is not as you posit here, as you may now infer:
Yes, some of the components depend on third-party libraries, but not all of them do, and, further, that’s not the rationale; the rationale is to allow easily updating dependencies in order to obtain bugfixes, security fixes, and new component features, while simultaneously allowing pinning specific components to specific versions or different constraints, all without requiring new versions of the framework metapackage.
If you really need to ensure that specific versions are installed, use the approach I outlined above to create a custom metapackage for your own application needs.
When version 3.0 was released, I also looked for the zip distribution, but today I do not see the need for it.
It is very easy to create update and manage Zend via composer. Given that I have little experience with this.
