Issue when installing this repository in an semi-up-to-date Magento2.4 Instance

[bytes-commerce]

Subject of the issue

I am trying to install this package for a Magento2 Project. However, it seems that its dependencies are locked, but experienced a major upgrade in the past, which causes the package to be non-require-able.

Your environment

• version of phpunitgen/core: none
• version of phpunitgen/console: none

Steps to reproduce

Tell us how to reproduce this issue. Please provide a working demo.

composer require --dev phpunitgen/console
    [...] 
    - Root composer.json requires phpunitgen/console ^1.5 -> satisfiable by phpunitgen/console[1.5.0].
    - phpunitgen/console 1.5.0 requires league/flysystem ^1.0 -> found league/flysystem[1.0.0, ..., 1.1.9] but the package is fixed to 2.4.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Expected behaviour

The module is required without an issue.

Actual behaviour

An issue is being thrown.

I like this tool a lot, so I would hope to see an update here! Thanks guys, its a neat and useful tool I like to use!! Thanks!

[paul-thebaud]

Hi @nopenopenope,

If you browse the code for console package at 1.5.0, you'll see dependencies are not "locked" by PhpUnitGen (there is no lock file). It looks like something in your dependencies require league/flysystem v2.

However, PhpUnitGen do require Flysystem package for file management: version 1.x.x for v1 and V2, and 3.x.x for v3. New implementations are using 3.x.x features, so I cannot just "add" 2.x.x.

Could you check your dependencies and see why flystem is already required at v2? After that, if it can be upgrade to v3, you might be able to install PhpUnitGen.

Why I'm not updating the package for now: your issue might be related to a soft locked dependencies which can be resolved easily without changes on my side. If the issue is finally due to PhpUnitGen deps, I might consider it again.

Thanks a lot!

[paul-thebaud]

PS: if you can share your composer.json without risks, I'll try to look at it on my free time :)

[bytes-commerce]

Hi Paul, thank you so much for taking the time to take on my issue I am experiencing.

root@b1c7340fc5b7:/var/www/magento2# composer depends league/flysystem
league/flysystem-aws-s3-v3         2.4.3    requires  league/flysystem (^2.0.0)  
magento/module-aws-s3              100.4.1  requires  league/flysystem (^2.0)    
magento/product-community-edition  2.4.3    requires  league/flysystem (^2.0) 

So, given from that, I cannot change the Flysystem version without risking to break the Magento2 core packages in favor of any other package.

I will evaluate some options, maybe I can use a single directory and point the composer json bin path to the original bin path, thus allowing me to "fake" it there.

[bytes-commerce]

Seems like I can fake it somehow with a new directory.

$ mkdir phpunitgen
$ composer init 
$ composer require phpunitgen/console
$ nano composer.json 

And add:

    "config": {
        "bin-dir": "../vendor/bin"
    }

Save, and re-run:

$ composer update

Now, when I run ls -lh vendor/bin from my root folder, I can see phpunitgen as expected. I am checking now if it works as expected and keep you posted.

UPDATE:

I have removed the bin-dir configurational value as it rendered the package unusable. Apparently its not a way of placing bins into other folders different to the parent dir of composer.json.

[paul-thebaud]

Hi, A solution for you (without any changes on your/my side) is to use the global installation method as stated in the documentation > CLI > Installation > Global installation.

[paul-thebaud]

I think this is cleaner that changing the bin-dir reference :) Tell me if it solves your issue!

[bytes-commerce]

Installing it via global parameter poses no option for us as it seems at this moment, as it would require us to persist some composer commands in our Dockerfile (unless I am missing something at the moment), which does not seem to be "okay"-ish in the context of a Php Dockerfile.

But hey, after adapting the default config, it works well for me. I had to require mockery/mockery in my main Magento2 folder, and now the Files resolve properly. I have figured out some improvements that I would like to see in the generator, but I will create new issues for that. Happy to discuss them with you, thanks a lot for your time and support and otherwise, happy Easter to you and your family.

[paul-thebaud]

Happy to see that you found what you wanted. If you want to leave mockery for the phpunit default mock system, you can use the phpunit mock implementation as stated in the documentation.

[KillianH]

Installing it via global parameter poses no option for us as it seems at this moment, as it would require us to persist some composer commands in our Dockerfile (unless I am missing something at the moment), which does not seem to be "okay"-ish in the context of a Php Dockerfile.

But hey, after adapting the default config, it works well for me. I had to require mockery/mockery in my main Magento2 folder, and now the Files resolve properly. I have figured out some improvements that I would like to see in the generator, but I will create new issues for that. Happy to discuss them with you, thanks a lot for your time and support and otherwise, happy Easter to you and your family.

I don't know your exact context but maybe you could use some multi stage docker build ? https://docs.docker.com/develop/develop-images/multistage-build/

[bytes-commerce]

Hi @KillianH, thanks for reaching out.

A multistaged build for, lets say, a Developer-only Dockerfile might work just as well, its an viable option when you have more complex Dockerfiles; however, personally speaking, I like to follow a similar principle applied to what SOLID is for OOP - the Dockerfile determines the Infrastructure and not the tools, so all setup should be done in responsible files. For composer it would be composer.json. However, this is totally just my opinion - other teams or developers might see it different. :)