phanan commented 4 years ago

Now that Composer 2 has been released, can we have it supported by the buildpack? Currently, composer.lock files generated by Composer 2 simply do not work with Heroku due to the Composer version being hardcoded.

dzuelke commented 4 years ago

It's of course already in the works, but what version is hardcoded? Composer 1 can still install from lock files generated by Composer 2.

The biggest incompatibility right now is with certain plugins and packages that explicitly require specific Composer versions.

For Heroku, v2 is not simply a drop-in replacement. The platform install step is implemented using a custom installer plugin and needs migrating to something that works with both v1 and v2.

Hoping it'll all be done end of next week.

phanan commented 4 years ago

Thanks for answering @dzuelke. I'm no Composer expert, but composer install with a v1 composer.lock file on Heroku yields this error:

         Problem 1
           - Installation request for jean85/pretty-package-versions 1.4.0 -> satisfiable by jean85/pretty-package-versions[1.4.0].
           - jean85/pretty-package-versions 1.4.0 requires composer-runtime-api ^2.0 -> no matching package found.
         Problem 2
           - Installation request for ocramius/package-versions 1.11.0 -> satisfiable by ocramius/package-versions[1.11.0].
           - ocramius/package-versions 1.11.0 requires composer-plugin-api ^2.0.0 -> no matching package found.
         Problem 3
           - jean85/pretty-package-versions 1.4.0 requires composer-runtime-api ^2.0 -> no matching package found.
           - sentry/sentry 2.5.0 requires jean85/pretty-package-versions ^1.2 -> satisfiable by jean85/pretty-package-versions[1.4.0].
           - Installation request for sentry/sentry 2.5.0 -> satisfiable by sentry/sentry[2.5.0].

So you're right, apparently composer-runtime-api ^2.0 (which comes with Composer 2) is required for certain packages.

pixels-noctulescents commented 4 years ago

Hello, same here, I'm having some troubles deploying a Symfony 5 application on Heroku :

Problem 1
- Installation request for ocramius/proxy-manager 2.9.1 -> satisfiable by ocramius/proxy-manager[2.9.1].
- ocramius/proxy-manager 2.9.1 requires composer-runtime-api ^2.0.0 -> no matching package found.
Problem 2
- ocramius/proxy-manager 2.9.1 requires composer-runtime-api ^2.0.0 -> no matching package found.
- doctrine/migrations 3.0.1 requires ocramius/proxy-manager ^2.0.2 -> satisfiable by ocramius/proxy-manager[2.9.1].           - Installation request for doctrine/migrations 3.0.1 -> satisfiable by doctrine/migrations[3.0.1].

Thank you and good luck with your work !

thomas-seres commented 4 years ago

Hello, Same problem here, is there a way to run "composer self-update --2" before composer install is launched ? It would help resolve the issue before composer 2 is officially supported.

Thank you !

YvanoDelavega commented 4 years ago

Hi, I solve this problem using the same version of composer as Heroku : version 1.10.13 (you can see it in the build log).

You just have to download "composer.phar" from "https://getcomposer.org/download/" and replace the existing one on your pc.
then, in "composer.json", delete the lines with "ocramius"
finally, in a terminal, do "npm update"

this will reinstall ocramius in a version compatible with composer 1.10.13 and so, with heroku also :)

hex333ham commented 4 years ago

@YvanoDelavega I wouldn't say this is a good solution to just downgrade composer (seems a bit like the nuclear option) but using v1 is helpful for debugging, you can also just put the phar in your projects directory and use it like normal composer but type composer.phar instead

for sticklers for proper versioning and/or you don't have the option to update composer (I'm testing DigitalOceans app platform on a personal project, stuck with this), you can downgrade the offending ocramius package ocramius/proxy-manager to 2.8.1 (or 2.8.* etc. to get updates) which is the version before the update - composer require ocramius/proxy-manager/2.8.1

https://github.com/Ocramius/ProxyManager/releases/tag/2.8.1

should also add, that's compatible with doctrines minimum stability requirements, as far as I can tell

you might have to regenerate your lock files but that's worked for me, not ideal I know

YvanoDelavega commented 4 years ago

@hex333ham, Thank you for your constructive answer. I know nuclear option is not an option, but, to tell the truth, i didn't know it was a nuclear option. Actually, i'm just a pure newbie with php, composer, heroku and all that stuff (I started a week ago)... So, i've juste find a solution to a reccurent problem and shared it with others because no one answered... Sorry if it is not convenient to you and all the pros, but may be my solution will help folks like me.

hex333ham commented 4 years ago

@YvanoDelavega it's no dramas man, happens, we all need to learn

if you just straight downgrade composer system-wide you can cause yourself issues with other projects that do require v2

it's a nuclear option in this sense that it's just making a large change when a smaller one would do, if that makes sense

stof commented 4 years ago

@dzuelke I think that for maximum compatibility, the buildpack should support both composer 1 and composer 2. Here is a suggestion:

ship composer1 and composer2 executables
based on the composer.lock file, guess the intended version (Composer 2 puts a plugin-api-version key in the lock file containing its plugin API version, allowing to detect when composer 2 was used) and create a composer executable by aliasing (or symlinking) the right one

For the special platform installation, it could keep using composer 1 for now, by using composer1 rather than composer to run the platform installation. Then, a separate step would be to rewrite the custom installer plugin to be compatible with composer 2 (and then, you'll have a choice whether you support both composer 1 and 2 or whether you force composer 2 for the platform installation). That would work as long as the custom plugin is loaded only for the platform installation and not when running composer for other commands.

dzuelke commented 4 years ago

Yup I've split it up that way now @stof to ship initial support quickly, except that Composer itself is now also installed using the Composer platform install step. Turtles all the way down!

phanan commented 4 years ago

Amazing work @dzuelke, thanks for taking care of this! What do we need to do to get Composer 2 into action, or will it just work seamlessly?

dzuelke commented 4 years ago

Nothing needed @phanan except maybe test it aggressively so we can iron out any kinks quickly.

447 is the PR, will be ready soon.

dzuelke commented 4 years ago

Test away @phanan, @stof, @hex333ham, @YvanoDelavega, @thomas-seres, and everybody else.

/cc @naderman @seldaek

mrailton commented 4 years ago

Thanks @dzuelke, looking forward to testing this.

dzuelke commented 4 years ago

(give the tag test runs ~ten minutes to complete before rollout to the platform can commence) /cc @railto

dzuelke commented 4 years ago

Ready when y'all are: https://devcenter.heroku.com/changelog-items/1954

Enjoy, please speak up if anything is wonky, and thanks for all the patience!

Happy weekend and happy pushing ✌️

heroku / heroku-buildpack-php

Support for Composer 2 #440

447 is the PR, will be ready soon.