Is there a way to micro-manage/edit dependencies at installation?

[abuyoyo]

Hi,
I've tried to find the answer to this in various searches, I've read the docs throughly, and I've gone over various StackExchange threads - but could not find anything that was cogent (to me, anyway). So I hope this is the correct place to post this question.

When running composer update or install, is there a way to programatically edit the install/update list in PHP, after Composer has resolved all the dependencies but before installation/update/write-to-disk?

To be more specific about my use-case.
I manage a few WordPress installations that I write custom plugins for. These custom WordPress plugins auto-update from GitHub repositories. The plugins (some of them) have regularly changing/updating composer dependencies.
The dependencies are all kept/managed in a single vendor dir used by the WordPress installation (which also has a composer.json file)

I'm looking for a way to
a. run Composer automatically/programatically on plugin update/auto-update. Preferrably from a PHP process and not through shell.
b. Have Composer update all of a plugin's dependencies but not the plugin itself. ie. I'd like to access the solved dependency list right before install and tweak it to remove any plugin managed by WordPress core - but still install all of its composer dependency libraries.

[Seldaek]

I can point you to https://roots.io/docs/bedrock/master/composer/#plugins as I know they have a good WP/Composer integration.

The rest of what you are asking.. running composer programmatically should definitely be doable (you can include the phar files and run it like https://github.com/composer/composer/blob/master/bin/composer#L63 does from CLI, except passing a StringInput for example). Modifying what gets updated not so much, you should rather run a composer update with the list of packages you want to update, then you can skip the others which are not listed, but if the plugins have new dependencies in a new version then you need to also update the plugin's version otherwise this won't work. Overall this sounds like a mess frankly to have a mix of WP updates and composer ones.

[abuyoyo]

Overall this sounds like a mess frankly to have a mix of WP updates and composer ones.

I concur. It is a mess. It's a mess right now. I'm just trying to code some of that mess away. There are certain routines I run manually on the installations I manage that I think I can do away with.

The custom plugins I have rely on WordPress auto-updates and that part is very reliable. Now and going forward. What is less reliable is those plugins' composer dependencies. As it stands I have to create a manual composer.json file per WordPress installation, with only the plugins' new dependencies - and run that seperately, manually and ahead of plugin auto-updates. It's this last bit that I'm wanting to automate.

you should rather run a composer update with the list of packages you want to update, then you can skip the others which are not listed

If I understand what you wrote correctly, this does not resolve my issue/use-case at all.

but if the plugins have new dependencies in a new version then you need to also update the plugin's version otherwise this won't work.

If it's possible to use the updated plugin's new/updated version to resolve the dependencies, and then, at the last minute, pull the plugin itself out - while leaving its resolved dependencies in - that would be very much the type of solution I'm seeking.

Modifying what gets updated not so much,

This is very disheartening news. Is this technically not possible - or just not recommended due to various issues that can arise?
I have no intention of distributing this code for general usage, simply to customize/control my very specific installations. I take full responsibility for any cluster-eff that may arise.

Am I correct to understand that there is no way to obtain a list of the resolved dependencies - and directly edit that list programatically (consequenses be what they may) just ahead of update/install?

[Seldaek]

Of course there is a way to do this, but there is no way to do this easily. You'll have to dig in the code a bunch, and it might be a maintenance nightmare as you'll rely on internal stuff we are not really expecting people to use and will possibly change without notice.

I'm not sure why you need to pull the plugin out of the updated deps..

I think actually what might be the easiest way altho it's gonna be rather hacky but that may be fine:

• Store a copy of lock file (A)
• Run a full update with --no-install to generate a new lock file (B) containing all updated dependencies
• Merge A and B according to whatever logic you want, to make sure pinned plugins from A are copied over those in B, to undo their update
• Run a composer install from this new merged lock file

[abuyoyo]

I'm not sure why you need to pull the plugin out of the updated deps..

Actually that's a good point I had not considered. My way of thinking was that if WordPress Auto-Update retrieves and installs the new/updated version of the plugin, Composer shouldn't. That part of the update process (the plugin proper - without its deps) is already done. But since they'll both be copying over the same files, from the same commit, it shouldn't be a problem for Composer to copy over the same plugin files again.

Getting and copying the same files twice is redundant - and very ugly code to my mind, but it should work. The bandwidth usage is less than optimal. ideally I'd only want to copy over the files once. But in truth I would want the lock file to reflect the new updated version.

So if I were to further narrow down my use-case, I guess I'd only want to skip over the redundant copying of the files, while leaving the rest of the Composer process intact - lock file and all.

[Seldaek]

I can't imagine the bandwidth of downloading a plugin is that high that it's worth hacking stuff around to avoid a single package's download? Sure it will copy the files over once more but that's in the grand scale of things not really worth thinking about IMO.