-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Pool::isPackageAcceptable optimisation breaks whatProvides() in Problem class #2661
Comments
@Seldaek which solution do you think is better? I guess keeping the list of names would just use up memory unnecessarily? |
@naderman I think improving the suggestions of solution would need something more generic. For instance, we should be able to decide whether the message concerning the minimum stability should be displayed (it should be displayed only if the package exists at a lower stability). |
Yeah that would probably help quite a bit, sounds good |
Yeah I'd agree that the whole error reporting has to be overhauled to be able to inspect the state of everything a bit more. |
This is broken again: http://stackoverflow.com/questions/36818363/composer-is-broken-class-fxp-composer-assetplugin-repository-npmrepository-does I'm using fxp/composer-asset-plugin (v1.1.4) and Composer version 1.0.2 2016-04-21 12:30:18. |
Had to remove |
The problem class uses the following code to inform the user that a package with a particular name does not exist at all. However since we no longer even load packages into the pool which cannot be useful in solving the dependency question (via
isPackageAcceptable
),whatProvides
will incorrectly return no results, even if the package exists but was skipped when adding the repository.We should probably keep around a simple list of names of all packages for errors, or provide a mechanism to retroactively search all repositories in an error case.
The text was updated successfully, but these errors were encountered: