Remove a package

[ElectricMaxxx]

Hi,
i think when composer req adds a package composer remove schould also remove the package's files and entries. At leas tthe entry in bundles.php should be removed as it causes errors.

[fabpot]

It should be the case already. Do you have a scenario where it does not work?

…

On 22 Sep 2017, at 12:30, Maximilian Berghoff ***@***.***> wrote: Hi, i think when composer req adds a package composer remove schould also remove the package's files and entries. At leas tthe entry in bundles.php should be removed as it causes errors. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ElectricMaxxx]

Yes i can an maybe it my fault:

I have got a blank symfony skeleton app with only cli requested (got a workshop tomorrow for the CMF) and wanted to request composer req symfony-cmf/routing-bundle. As that one has no reciepe yet, the bundle is called the way as it was done before except the entry in bundle.php. The cache-clear fails because of missing dependencies. Missing as bundle.php entries and missing as configuration. So a i tried to do it step by step and tried to remove by composer remove symfony-cmf/routing-bundle, which removes the bundle but not th bundle.php entry as it fails in between for the same reason the cache-clear failed before.

So in german we call that Henne-Ei-Problem(Chicken-Egg-Problem). With the requested package with dependencies the app fails cause the dependencies are not registered inside bundle.php, cause i have no reciepe yet. Registering the dependencies before requesting the package and adding the configuration will fail, when the bundle has a reciepe later. Or should we make our bundle fail safe an registering the bundle without a configuration? (In our case a service requested an other service, which wasn't available without registering the service's bundle) I mean the same error occurs in Symfony 3.2 when register my bundle only. But with flex it is done automaticially.

[ElectricMaxxx]

When there are no errors (dependencies are clean) the bundle is unregistered, but the gerated/copied configuration file stayed.

[ElectricMaxxx]

btw: i think i found a runnig configuration/reciepe for our routing-bundle: symfony/recipes-contrib#91 (comment)

[ElectricMaxxx]

Based on the discussion of symfony/recipes-contrib#91 if found out, that the bundles.php is handles correctly, when there are no issues while installing packages, but when removing a package the configuration file isn't removed.

[ElectricMaxxx]

@fabpot I would suggest to two things:

• on composer remove X/Y revert complete reciepe (bundle.php, copied files)
• on an Error whild composer require X/Y trigger that complete revert. Composer itself removes composer.json Entry

Doing so an invalid state (bundle registration + no configuration, bundle registration + missing dependencies) would never exist. We should force the libraries to deliver all their dependencies, we should force the user to priory configure, when there is no reciepe.

[fabpot]

The first item is what Flex already does.

[ElectricMaxxx]

Yes you are right i got the issue. And maybe we should add it into the docs or you blog: To remove a bundle which is on its way to get a reciepe, means which sill has a PR we also need the SYMFONY_ENDPOINT:

$ SYMFONY_ENDPOINT=https://symfony.sh/r/github.com/symfony/recipes-contrib/91 composer req symfony-cmf/routing-bundle
$ composer remove symfony-cmf/routing-bundle
# then ...
$ ls config/packages
/cmf_routing_bundle.yaml  dev  framework.yaml  routing.yaml  test

# but with ....
$ SYMFONY_ENDPOINT=https://symfony.sh/r/github.com/symfony/recipes-contrib/91 composer remove symfony-cmf/routing-bundle
# then ...
$  ls config/packages
/dev  framework.yaml  routing.yaml  test

Makes sense as flex needs to know about the reciepe.

[stof]

@fabpot are you sure that auto-generated recipes are removing the bundle class properly on package removal ? If the auto-generation happens after the filesystem removal, the class would not exist anymore.

[fabpot]

Yes, because on uninstall, we try to remove all possible variations of bundles names. So, we don't need the code. This algo was broken on one version of Flex (1.0.22).

[fabpot]

Closing as there is no bugs here.