Remove files when updating a recipe

[maxhelias]

Fix issue #593 and https://twitter.com/nicolasgrekas/status/1252292768296308736

@nicolas-grekas tell me if it's ok as it's a little "hack"

[nicolas-grekas]

Thanks for starting this!
I had another idea that I tried to described on Twitter.
I think the current approach won't work when a file is referenced by several recipes (eg phpunit.xml.dist). We should remove the files only when they are not referenced by any recipe (like the "remove" operation does).

So, actually, maybe the correct approach is to remove recipes just before applying them again. This would mean that the current check that asks confirmation before a file is overridden should be moved before the removal happens.

I'm writing this without having opened the code, please check if it makes any sense :)

[weaverryan]

I think the current approach won't work when a file is referenced by several recipes (eg phpunit.xml.dist).

That's a really good point

So, actually, maybe the correct approach is to remove recipes just before applying them again

I think this would be great! But to do this, wouldn't we need the ability to "fetch the original recipe" so that we can remove it? If we ran an unconfigure option on the latest version of the recipe, it wouldn't delete files that have been removed from the recipe. Right?

[nicolas-grekas]

wouldn't we need the ability to "fetch the original recipe" so that we can remove it?

For files, we don't need to, they are already listed in symfony.lock
For other things (.env, .gitignore, etc) yes - we could put the manifest in symfony.lock when installing a recipe, that would solve this aspect also.
Note that to me, files account for 95% of the problem we want to solve, and we have everything to solve these 95% already.

[weaverryan]

For files, we don't need to, they are already listed in symfony.lock

Are you saying that we should, sort of, use the files from symfony.lock to create a Recipe object and then unconfigure that? That sounds reasonable to me - though there may be some work to create a Recipe object from this other, "incomplete" source.

For other things (.env, .gitignore, etc) yes - we could put the manifest in symfony.lock when installing a recipe, that would solve this aspect also.

That's a really good idea :). We could also show more details when viewing a recipe with the composer recipe command... without needing API changes.

[nicolas-grekas]

create a Recipe object from this other, "incomplete" source

that, or we implement a dedicated file deletion logic that focuses on the side effect: refcounting files and removing those that are referenced only by recipes we're about to resync.

[weaverryan]

Ping @maxhelias! What do you think about the proposals here? Do you have time to update the PR?

Thanks!

[maxhelias]

I think a dedicated file deletion logic should be a good idea but i don't know if i have time to do it, i'll try within a week. So don't hesitate if you want to fast-forward this

[weaverryan]

Friendly ping @maxhelias if you have some time :)

[maxhelias]

Hi @weaverryan, i'm not sure to have time to finish that

[maxhelias]

close in favor of #667