Flex: Approach to keeping symfony.lock up-to-date

Created on 9 Aug 2018  路  10Comments  路  Source: symfony/flex

Hey team,

I run a service that automatically creates PRs to keep composer.json and composer.lock files up-to-date. A user asked me whether the service could/should also update the symfony.lock file when it updates dependencies, and I realised I wasn't sure.

I had a look for documentation on what the symfony.lock file is for and read through this question and some of the docs on recipes, but I'm still uncertain whether a hosted service like Dependabot should be updating it.

My hunch is that services like Dependabot shouldn't update the symfony.lock, because its role is to ensure that scripts only run once, and they wouldn't be running at all on Dependabot (we only update dependency-related files). Is that correct?

Most helpful comment

It probably makes sense to apply Flex recipes then too. However, committing them automatically seems to be too risky to me. Such changes should always be reviewed by a human being in the context of the application.

All 10 comments

How does your service deal with dependency updates that lead to new packages being installed? I can imagine that there could be scenarios where a new package is installed due to an updated dependency for which a recipe is defined. How would that be applied?

If a dependency update causes a new sub-dependency to be added then the service adds its details to the composer.lock, basically in exactly the same way that Composer would (we mess with the internals of Composer under the hood to speed it up, but we're essentially running composer update <dep-name>.

It probably makes sense to apply Flex recipes then too. However, committing them automatically seems to be too risky to me. Such changes should always be reviewed by a human being in the context of the application.

Dependabot only ever creates PRs, so that should be fine, but looking through the configurations available to libraries I think it's going to be tricky for Dependabot to apply all of the changes that recipes are capable of applying (particularly copy-from-package). Dependabot doesn't clone repos - it just pulls down dependency-related files - so making changes to non-dependency files is kind of out for us.

What happens if a symfony.lock files is out of sync with a composer.lock file (as would be the case if Dependabot didn't update it, but did update the composer.lock)? Will it be updated and apply the relevant recipes next time a user runs composer install?

(And thanks for the guidance - really appreciated!)

If I correctly understand the workflow, they will have to run composer fix-recipes.

Is there a specific reason that your service does not use Composer itself to update packages?

Mainly speed (avoiding the install post-resolution), but there are some other customisations we need to make to run on our infrastructure. As s result, it makes more sense for us to use the Composer internals than the CLI (code is here if I'm being unclear).

OK, and if we were to update the symfony.lock file but not commit the changes from running the scripts (which we wouldn't be able to commit in all cases, because we haven't cloned the repo), presumably that would be worse than requiring folks to run composer fix-recipes because the user would have a lockfile that looked up-to-date but had, in fact, not had its recipes applied?

Shall we close after https://github.com/symfony/flex/pull/439 is merged?

(assuming yes - closing)

馃憤 from me - thanks for the help on this one @xabbuh!

Was this page helpful?
0 / 5 - 0 ratings