Provide rules in the composer.json are wrong #2

New Issue

Ghost · 2020-10-22T09:20:14-04:00

Ghost commented

2020-10-22 09:20:14 -04:00

The composer.json currently provides psr/cache and psr/simple-cache, while also requiring them. This is wrong. psr/cache is the package containing the definition for PSR interfaces, and this code is definitely not provided in this package.
The actual provide rules should be psr/cache-implementation and psr/simple-cache-implementation.

Providing the wrong package while also requiring it creates issues with Composer 2, because the solver will consider that installing psr/cache is not necessary as it is already provided (Composer 1 still installs the package in that case, as it does not respect provide rules when a package actually exist with this name).
See https://github.com/composer/composer/issues/9316 for a report on such issue (on a different PSR package) and https://github.com/composer/composer/issues/9311 which discusses adding a validation rule to catch the common mistake (which would have caught it here).

The `composer.json` currently provides `psr/cache` and `psr/simple-cache`, while also requiring them. This is wrong. `psr/cache` is the package containing the definition for PSR interfaces, and this code is definitely not provided in this package. The actual provide rules should be `psr/cache-implementation` and `psr/simple-cache-implementation`. Providing the wrong package while also requiring it creates issues with Composer 2, because the solver will consider that installing `psr/cache` is not necessary as it is already provided (Composer 1 still installs the package in that case, as it does not respect `provide` rules when a package actually exist with this name). See https://github.com/composer/composer/issues/9316 for a report on such issue (on a different PSR package) and https://github.com/composer/composer/issues/9311 which discusses adding a validation rule to catch the common mistake (which would have caught it here).

Ghost commented

2020-10-22 09:20:51 -04:00

Note that I tried forking the repo and sending a pull request with the fix directly, but that triggered a 500 error.

timw4mail commented

2020-10-22 09:44:49 -04:00

Thanks! I don't I've seen clear documentation on the provides section. I'll have a look and push out a new tag soon.

I probably have this done incorrectly on a few other packages too, so great to know.

Note that I tried forking the repo and sending a pull request with the fix directly, but that triggered a 500 error.

500 on the fork, or the PR?

Thanks! I don't I've seen clear documentation on the `provides` section. I'll have a look and push out a new tag soon. I probably have this done incorrectly on a few other packages too, so great to know. > Note that I tried forking the repo and sending a pull request with the fix directly, but that triggered a 500 error. 500 on the fork, or the PR?

timw4mail commented

2020-10-22 10:06:48 -04:00

I believe this commit, and the newest tag should resolve the issue:
624e0efd97

Can you verify, @stof?

I believe this commit, and the newest tag should resolve the issue: https://git.timshomepage.net/aviat/banker/commit/624e0efd971e8bd6d6a7af83010291e79c48c473 Can you verify, @stof?

Ghost commented

2020-10-22 11:14:37 -04:00

500 on the fork, or the PR?

On the creation of the fork

Can you verify, @stof?

this commit indeed fixes it.

> 500 on the fork, or the PR? On the creation of the fork > Can you verify, @stof? this commit indeed fixes it.

Ghost closed this issue

2020-10-22 11:14:43 -04:00

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: aviat/banker#2