Comments (10)
Well, it's been 2 weeks and I've got no feedback.
Anyway, I went ahead and I tried to use zf1s with zf1-extras and there are 2 problems,
- There are a lot of
require_once
in zf1-extras codebase which don't resolve with zf1s - zf1s is NOT a drop-in replacement for zf1, as it does NOT / cannot inherently specify in the
composer.json
a definition like,
"replace": {
"zendframework/zendframework1": ">=1.12.20"
}
All this means that we would need to fork zf1-extras, remove the require_once
statements, adjust the code to make it work including the unit tests, put those tests under CI for php compatibility review, etc.
Basically when someone uses zf1s it alienates itself from using other components which could provide features to zf1, for example,
- https://github.com/PHP-DI/ZF1-Bridge
- https://github.com/guilhermeblanco/zendframework1-doctrine2
- https://github.com/jokkedk/ZFDebug
- https://github.com/Shardj/zf1-extras-future
from zf1.
@fredericgboutin-yapla now full zf1s/zf1
package is available. https://packagist.org/packages/zf1s/zf1 v1.15.0 - please try.
from zf1.
I'm trying right now and I stumbled on something interesting,
composer require zf1s/zf1:^1.15.0 shardj/zf1-extras-future
PHP 7.0.33 (cli) (built: Dec 29 2018 06:50:58) ( NTS )
[InvalidArgumentException]
Package zf1s/zf1 has requirements incompatible with your PHP version, PHP extensions and Composer version:
- zf1s/zf1 1.15.0 requires ext-ldap * but it is not present.
So, there is a requirement for the LDAP extension in the monorepo composer.json
file,
Line 11 in be1785d
Which makes sense since there is an LDAP module with the same requirement 👍 - https://github.com/zf1s/zend-ldap/blob/6569d32d80e162424c33450e0d9135a74af5212a/composer.json#L9
The problem is, we don't use LDAP so, as a work around I must modify my composer.json
by adding,
"config": {
"platform": {
"ext-ldap": "1"
}
}
I could have also called composer with --ignore-platform-req=ext-ldap
but that's cumbersome.
Anyway, I retried the initial composer require
and this time I got a 2 warnings when generating the autoload files,
Class Zend_Tool_Framework_Provider_DocblockManifestInterface located in ./vendor/zf1s/zf1/packages/zend-tool/library/Zend/Tool/Framework/Provider/DocblockManifestable.php does not comply with psr-0 autoloading standard. Skipping.
Class Zend_Gdata_Analytics_Goal located in ./vendor/zf1s/zf1/packages/zend-gdata/library/Zend/Gdata/Analytics/Extension/Goal.php does not comply with psr-0 autoloading standard. Skipping.
Not a big deal but still probably something to iron out.
I confirm that the original zendframework/zendframework1
package was NOT downloaded nor installed in the vendor
folder. The lock file also confirms that the new replace
statement introduced in 1.15.0
works as expected.
From my perspective, I can say it works.
Now, like you predicted / as expected the require_once
statements in Zend Extras don't work, for example
Warning: require_once(Zend/Json.php): failed to open stream: No such file or directory in /var/www/html/vendor/shardj/zf1-extras-future/library/ZendX/JQuery.php on line 26
from zf1.
Thank you for sharing your findings @fredericgboutin-yapla !
Those two classes Zend_Tool_Framework_Provider_DocblockManifestInterface
and Zend_Gdata_Analytics_Goal
deserve a fix to rename/move their files so that composer autoloader does not complain.
As for php extensions listed in require
section.. you might be right, it is probably too restrictive at the moment. Due to the nature of zf1, you may never need some of the extensions, as long as you do not use components which require them. But when you start using them, those components themselves should throw errors that required extensions are not installed.
@glensc did great job in #6, filling the requirements for each component individually. Then right after that PR got merged, I went ahead and added them to the main composer.json
in fdf41f3, without a PR, but pushing directly to master
🙈 Why, I don't remember anymore.
I suppose they could be added to suggest
section instead, or dropped entirely from the main composer.json
🤔
from zf1.
if you remove extension require from root composer.json then our CI can't validate what extensions are required. otoh, the requirements will likely never change and they already are present in CI configs. but if the base image changes extensions included, our jobs have no way to validate what are required. and some tests are just silently skipped if extension is missing and we might not notice we are skipping some tests.
so, mixed feelings here again :)
but of course we could do some hacking like transform all suggests to require in our ci job. something similar done here:
- eventum/eventum#1291
- the script: https://github.com/eventum/eventum/blob/ee44a032bfdfed61e14bc0f382fa0abc9ba5151d/bin/releng/composer-replace.sh
from zf1.
@falkenhawk I had to bootstrap zfdebug from https://github.com/jokkedk/ZFDebug with zf1s and I think I basically found something interesting. I truly had to understand what require_once
is,
Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include will finally check in the calling script's own directory and the current working directory before failing.
Since I don't want / I'm unable to modify all the require_once 'Zend/[...]';
out there I decided to brute force things with a bunch of include-path
in my composer.json
- https://getcomposer.org/doc/04-schema.md#include-path
"include-path": [
"vendor/zf1s/zend-acl/library",
"vendor/zf1s/zend-application/library",
"vendor/zf1s/zend-auth/library",
"vendor/zf1s/zend-cache/library",
"vendor/zf1s/zend-config/library",
"vendor/zf1s/zend-console-getopt/library",
"vendor/zf1s/zend-controller/library",
"vendor/zf1s/zend-crypt/library",
"vendor/zf1s/zend-date/library",
"vendor/zf1s/zend-db/library",
"vendor/zf1s/zend-dom/library",
"vendor/zf1s/zend-exception/library",
"vendor/zf1s/zend-file-transfer/library",
"vendor/zf1s/zend-filter/library",
"vendor/zf1s/zend-form/library",
"vendor/zf1s/zend-json/library",
"vendor/zf1s/zend-layout/library",
"vendor/zf1s/zend-loader/library",
"vendor/zf1s/zend-locale/library",
"vendor/zf1s/zend-log/library",
"vendor/zf1s/zend-measure/library",
"vendor/zf1s/zend-navigation/library",
"vendor/zf1s/zend-paginator/library",
"vendor/zf1s/zend-registry/library",
"vendor/zf1s/zend-server/library",
"vendor/zf1s/zend-session/library",
"vendor/zf1s/zend-test/library",
"vendor/zf1s/zend-translate/library",
"vendor/zf1s/zend-uri/library",
"vendor/zf1s/zend-validate/library",
"vendor/zf1s/zend-version/library",
"vendor/zf1s/zend-view/library",
"vendor/zf1s/zend-xml/library"
],
And it works 🥳 but it's ugly 💩
In fact, the original Zend composer definition had an include-path
statement - https://github.com/zendframework/zf1/blob/master/composer.json#L19
So, my hypothesis here is to simply provide an equivalent definition, both for the monorepo (which I don't use in my example) and every single modules.
UPDATE: I tried with a wildcard but Composer doesn't support it seemingly.
from zf1.
Yes @fredericgboutin-yapla that's exactly what you need to do if you need to combine zf1s with zf1 extensions which still utilize require_once... and yes it is ugly and potentially may affect general php performance regarding file lookups (although I am not sure about that, only guessing) so I would not want it to be added to the main composer.json of zf1s so that it affects everyone.
It's a matter of finding a compromise - either forking/patching old codebase for zf1 extensions, or adding include-path for all components in your project. Or switching to zf1-future, diablomedia, etc. forks :)
Again, thanks for sharing!
from zf1.
But perhaps worth adding this to readme, no performance impact there ;)
from zf1.
ok. moving to require-dev is better, I didn't think of that:
from zf1.
As for php extensions listed in require section.. you might be right, it is probably too restrictive at the moment. Due to the nature of zf1, you may never need some of the extensions,
To be fair, I personally think it is alright. The workaround I came with is good because I had to explicitly acknowledge the requirement and deal with it somehow. I basically like being told of extension requirements.
But yeah, if I had to deal with half a dozen... and figuring transitive dependencies between different Zend modules to understand what I'm really entitled to... but still, I think it is probably a fair drawback of using the monorepo at the first place - i.e. by default you are required to fulfill all the extension requirements.
from zf1.
Related Issues (20)
- zf1s/zend-ldap doesn't work with PHP8 HOT 8
- Resolve or suppress PHP 8.1 deprecation notices HOT 6
- Pin zf1s org repositories HOT 1
- Cross-package dependencies HOT 5
- Zend_Session_SaveHandler_DbTable causes a warning under PHP 7 when the row is unchanged HOT 3
- Zend Session would throw an exception "The session has already been started. The session id must be set first." upon receiving an invalid session ID HOT 8
- unnecessary Zend_Uri dependencies HOT 2
- Zend_Locale doesn't seem to be a necessary dep of Zend_View
- Session Savehandler DbTable Warning HOT 1
- Merge with zf1-future HOT 9
- Zend_Db_Adapter_Pdo_Pgsql is broken with Postgres 12 HOT 3
- iconv_substr behaves differently under PHP8 HOT 10
- During launch of a new version, composer can pull in dev-master HOT 8
- php 8: The track_errors ini directive has been removed HOT 7
- Zend_Translate issues 'failed to open stream' warning when using a custom adapter HOT 4
- PHP 8.0 porting status HOT 9
- publish monorepo composer package HOT 4
- Class Zend_Application_Resource_UserAgent located in ./vendor/zf1s/zend-application/library/Zend/Application/Resource/Useragent.php does not comply with psr-0 autoloading standard.
- Merge with diablomedia/zf1 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zf1.