composer / satis

Simple static Composer repository generator - For a full private Composer repo use Private Packagist
MIT License
3.14k stars 518 forks source link

Change "replace" to "provide" in composer.json #930

Closed rkrahnen closed 1 week ago

rkrahnen commented 2 weeks ago

Describe the bug I have the problem that the "replace" for polyfills leads to an uninstallable set of packages because another package also uses "replace" for the same polyfills.

To Reproduce Use the following composer.json and run composer update.

{
    "name": "test/test",
    "type": "project",
    "require": {
        "composer/satis": "dev-main",
    "neos/flow": "^7.3.19"
    },
    "autoload": {
        "psr-4": {
            "Test\\Test\\": "src/"
        }
    }
}

Outcome

Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires composer/satis dev-main -> satisfiable by composer/satis[dev-main].
    - Only one of these can be installed: symfony/polyfill-php73[v1.19.0, ..., v1.31.0], composer/satis[dev-main, 3.0.x-dev], neos/flow[7.3.19]. [composer/satis, neos/flow] replace symfony/polyfill-php73 and thus cannot coexist with it.
    - Root composer.json requires neos/flow ^7.3.19 -> satisfiable by neos/flow[7.3.19].

Expected behavior If I understand the Composer documentation correctly, several packages can deliver the same "provide", whereas a "replace" can only deliver one package. To avoid conflicts with other packages, I would suggest replacing "replace" with "provide".

Additional context I know that in my example the requested change would still lead to an uninstallable set of packages due to conflicting version constraints for symfony/console, but that is another topic. :-)

alcohol commented 1 week ago

Using provide does not have the same benefit for us as a root package. Those polyfills will still be installed. But there is very little harm in having them installed, so I have no objection to removing them if it makes things easier for users who use composer/satis as a library (require) for their own project.

rkrahnen commented 1 week ago

First of all, thank you very much!

Are you sure that provide does not have the same benefit for you? I just installed the project with composer create-project --keep-vcs --no-dev composer/satis:dev-main and the polyfills were installed because you removed the replace block. I then added the block again, but with provide and a composer update --no-dev removes the polyfills.

alcohol commented 1 week ago

Looking at the distinction between them (provide vs replace), I guess that should work too. But since we do not actually enforce a minimum php version requirement (and I would prefer to avoid that to allow more flexibility for those using composer/satis as a library), it might actually be safer to just not list them.

rkrahnen commented 1 week ago

I agree with not enforcing a minimum php version. 👍

Thanks for the quick reply!

alcohol commented 1 week ago

I agree with not enforcing a minimum php version. 👍

I misspoke. In a way we do enforce it because the constraints of our dependencies are bumped occasionally. See https://github.com/composer/satis/commit/2df25498b62080d0ab088347e2b63f671056eae8 for reference.