Composer install requirements (without a lock file) #10013
Replies: 2 comments 4 replies
-
this isn't facepalm
this is See https://blog.engineyard.com/composer-its-all-about-the-lock-file for a good explanation.
What would that flag be named? You have to use Composer knowing what you are doing, not trying commands until they work. You know if you have |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure I get your first point - ignoring composer.lock isn't a facepalm, but here's a link saying why it's important to have and to commit it? That link is pretty much why I'd say adding it to gitignore is a facepalm... My thought on the flag would be more like I'd agree it helps to know what you're doing, and don't think composer needs to hold everyones hand, but it also feels weird to have a oft-used desired command automatically turn into a potentially undesired one automatically based only on the presence of a file. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, f**k me, I've pasted wrong link 🤦🏼 I meant this: https://phil.tech/2014/composer-its-almost-always-about-the-lock-file/ with addition of https://www.dereuromark.de/2019/01/04/test-composer-dependencies-with-prefer-lowest/ - the key point is to know the difference between an application and library. I love this quote from Sebastian Bergmann: sebastianbergmann/phpunit#3112 (comment) - for this discussion replace "upload PHPUnit" with "do not upload composer.lock". |
Beta Was this translation helpful? Give feedback.
-
|
This was an application, but it's interesting understanding more about the lock and it's nuances. The deployment process / instruction was definitely at fault here - I've changed a few things and added a check to ensure there is a lock file present so composer only installs, not updates, but still kinda feel there ought to be a way to not chain those commands. Not that I have any intention to need one in future ;) |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we really want to spend much effort optimizing this case away, as it's fairly special, and frankly quite rare that you'd find a PHP requirement that cannot be fulfilled in the root package. Any other requirement than platform ones we can't really do a fast fail we'd have to load all packages to know if it can be resolved. What I wonder though is whether you are using Composer 1 or 2, because it seems to me like v2 should ideally not kill a t2.small instance.. But that definitely depends a lot on your project's composer.json and dependency graph. |
Beta Was this translation helpful? Give feedback.
-
|
It is composer 2 - first time I've hit any memory issues since leaving 1 I think. (Really speaks to your phenomenal work on that update!) It does seem like a specific dependency is causing the issues, and can't replicate any problems without that, so guess the use case for a fast-fail is very minor. Appreciate putting any major effort into special (and somewhat stupid) use cases like this is minimal benefit, but I was also kinda surprised it could take down the whole instance so it felt like a problem worth discussing in case the use case/effect/effort ratio balance was more significant than not. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Doing this as a discussion as I hit some problems that are clearly more my issue then composers, but wanted to share in case it is felt it might be worth resolving somewhat within this project.
Story is I tried installing a repo that git ignored composer.lock (I know 🤦🏼 ). This ended up locking up the CPU of an aws t2.small instance for long enough (5+ mins) that I gave up and rebooted it. It didn't even get to listing out the depencies for download, just warned there was no lock file then got stuck after
Loading composer repositories with package information. Updating dependencies.Tried it on a local clone and had to run with
memory_limit=-1as it hit a memory exception, before eventually it told me it couldn't resolve as it needs php7 and I was using php8. (The server also uses php8, so would presumably eventually have stopped in the same way had I let it continue)I appreciate this is best solved by A) Always include the lock file B) install with the right PHP version. However it does feel like something is a bit off here from what I'd expect to happen in this foolish scenario.
The composer.json has:
Is it as intended that it may need "significant" memory / cpu to realise that top level php requirement isn't met? I assuming it's recursively checking all the packages so as to give a full list of all problems (and one is probably very heavy here), but if the root composer.json isn't met is there really an advantage in continuing? IDK if a fast-fail would matter for many other root options, but it feels kinda weird that it needs to do a big process even if the basic php concern isn't fulfilled.
More generically are the requirements for running
composer installwith no lock such that you would never recommend running install without the lock file on a server? Or does this vary so much with the packages / server specs there's not a clear answer?Currently I can see no "safe" way to install only from a lock file - if there's no .lock it will warn you, but then it immediately starts the more expensive process of generating one anyway. Handy on local; but not great on a smaller server. Would you consider having a flag, or alternative install command that just stops if there's no lock file to work from?
Beta Was this translation helpful? Give feedback.
All reactions