Should package removes run through the DeployManager?

[AydinHassan]

Now we have the ability to attach to events in the DeployManager should package removes also be coordinated by the DeployManager?

Currently the strategy is manually run for uninstalls, see here and here.

This contrasts with how the installs are done (they are triggered via the DeployManager), before, I was under the impression that uninstalls also ran through the 'DeployManageras I thought I could removegitignore` entries on uninstall via a listener, however, this is not the case.

How could we implement this in a nice way?

I see a problem - In the update method, the package needs to be removed and then re-installed, the doDeploy method, as I see it, would need to be called directly in MagentoHackathon\Composer\Magento\Installer\InstallerAbstract::update method before the call to parent, as after that the files are no longer there and we wouldn't actually know what files to remove in the case of globs, etc.

It would then need to be called after the update. This seems a bit hacky, does anyone else have any ideas?

Further than actually storing the installed file list somewhere I can't see a great way of doing this.

[Flyingmana]

Thats exactly the reason, why I needed to know which package the deployed file is from. The Plan is, to use this functionality to track every single file, and to which package it belongs, and use this list to remove all files from a package on update and remove. So it is enough if it happens before the deploy, but its not necessary to do it before the package got touched/removed/updated in vendor.

I already tought about the storing format and experimented a bit. My first plan was to imitate the package.xml magento uses itself, but the format is a cruel mix of Pear1 and Pear2 and introduces things not allowed in any of them both.... So, I would say we use a simple and own format. Location I would chose inside the vendor by default but configurable, so others can for example put it into the root or the var directory, for example if they want to maintain this list via a vcs, but dont want to commit the whole vendor.

[davidverholen]

yes that's how it works in our installer, too. You can easily store the mappings array as json data somewhere and then on remove or update action load those data files and remove the deployed symlinks/files.

You could also use something like https://github.com/doctrine/oxm to store the data as xml (not sure if there is something equal for json)

I have tested the Marshaller and it works great. Did not test the repository and entitymanager yet.

[AydinHassan]

Cool sounds good, I will do a bit of research in to this. Tbh I would rather not use XML. JSON would be my preferred format. Shame we can't hook in to Composer's repository and save data in the installed.json file or maybe we can, I'll poke around a little bit. Looks like theres an ArrayDumper hard coded in one of the repsoitory classes, maybe we can extend that and replace the repository in Composer at Runtime.

[Flyingmana]

json is ok for me. But as part of the installed.json is risky I think. And would not work for me, as I commit the modules, but not the vendor directory in my current project. And I think a lot still commit their whole projects.

[AydinHassan]

Ah yeah that makes sense :+1:

[AydinHassan]

I rekon we could crack this with a listener with pretty minimal code