-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trips up when presented with non-standard packages #22
Comments
Separately, though related, is the case of 'provides' type requirements, such as php-http/client-implementation. Obviously these should be excluded (as presumably a providing package is being required somewhere and will be picked up by Strauss separately), and this can be done manually in the strauss configuration for the root package, but skipping these automagically would be nice, though I am not sure how possible this is. |
Looks like the Packagist API will help address packages like league/omnipay. Probably by doing ~ I didn't notice that Strauss handles the I'm busy for the next week but will take a look into this afterwards. |
OK, I've a branch with passing tests: It's reading the meta package from composer.lock (which I looked for before but thought it wasn't there!) and is ignoring the virtual package. There some code duplication that needs to be tidied up: strauss/src/Console/Commands/Compose.php Lines 110 to 235 in 78cf834
And it needs a test with a package that requires a virtual package. And needs to be tested on Windows. |
I pushed some more changes to the branch. I don't foresee any more. Once I get a chance to write a few lines in the README I'll merge and push a new release to Packagist. |
As metapackages do not follow the standard directory structure, Strauss has trouble dealing with them, as it cannot find their composer.json. An example of this can be seen by requiring league/omnipay. A workaround for this is to require the packages from the metapackage separately, but it would be more elegant if Strauss could handle this gracefully.
This also applies to other non-standard package types. For instance, if requiring composer/installers such that we can declare our package as a wordpress-plugin, rather than a library, strauss is unable to locate the package 'composer-plugin-api' and fails to compose dependencies.
I am unsure the best way to deal with these special cases - Perhaps at least in the case of composer-plugin-api we simply exclude this package by default
The text was updated successfully, but these errors were encountered: