When it is installed, Package Manager should try to detect the paths of Composer and rsync

1. if Package Manager is installed at the command line (as is the case in the Starshot prototype, or any time Drush installs Package Manager).

   Why does this apply more to command line then the web install? Won't the logic be the same in either case?

2. What happens if you installed package manager locally, the config is automatically set to /local-path/composer but then you deploy the site to server with config and composer is at /server-path/composer. Won't package manager fail because composer is not at /local-path/composer and won't try to find it because the config is set.

   As it is now if you install package manager locally and package manager can find Composer and then you deploy to a server and Package Manager can also find Composer but it is at different path then it will work in both places.

   But as I understand this change depending on how you deploy config then this will no longer work.

3. If 2) is right could you not just handle this in the Starshot repo as it more defined use case where you can assume more things.

   Especially since I don't think we have ever had a issue filed from actual use complaining about this problem. My guess is usually Package Manager finds Composer and Rsync without a problem

Feels like a target rather than a blocker, not that I am trying to discourage :)

I spoke to Ted about this today and I think we are finally agreed that this is really necessary for Package Manager. Too many people have run into this problem for us to keep kicking it down the road. It should be fixed in core first, then backported to contrib, so I'm moving this issue to core's queue.

The point about accidentally exporting invalid paths in config is well-taken, so I propose we create an event subscriber that responds to the ConfigEvents::STORAGE_TRANSFORM_EXPORT event and removes those values from exported configuration.

On top of that...I think we need a settings form -- the first and hopefully only UI in Package Manager -- to set these values.

phenaproxima → closed merge request !1085

phenaproxima → changed the visibility of the branch 3463662-when-it-is to hidden.

Needs tests but this is reviewable.

People are definitely running into this a lot with Drupal CMS, lots of reports in slack.

The point about accidentally exporting invalid paths in config is a good one, though, so I propose we create an event subscriber that responds to the ConfigEvents::STORAGE_TRANSFORM_EXPORT event and removes those values from exported configuration.

That would avoid a config deployment breaking a remote site, but what happens on import from local - won't it override the set values to empty again?

I was going to suggest using key/value a bit like https://www.drupal.org/project/drupal/issues/3437162 📌 Move twig_debug and other development toggles into raw key/value Fixed but that would also get overwritten on a sync back from production so just moving things to a different place.

Then I was thinking could we determine these on config import. But if we can keep determining them whenever we want, and assuming #6 is correct and this will work on non-cli, then what about first trying to find the executable, and then using executable locator, but then caching the location.

That way if the executables are in $PATH nothing runs, if they're not, it does the lookup whenever, but no syncing involved.

Then it could do a final fallback to the config value - although after all the above, wondering if that should move to $settings so it's easier to make it environment-specific.

Hmmm...those are very good points. I guess config sync won't work.

At the very least, though, there should be a UI to change these values. Forcing people to do it with Drush is not doing us any real favors, and it might not even be possible for people who are on shared hosting without SSH access.

Could we rescope this issue (or make a new issue) to add a settings form, and figure out auto-detection later?

I think that should be a separate issue because if config and k/v don't work for storing this, where is the setting going to be written to, but also definitely worth exploring.

Based on slack seems there may still be some work needed here.

Reading comments in related issues this feels more like major task than normal feature request.

I think we could use this as a hint on the settings page which is being added sin the other issue.

And we could also locate and cache this as a fallback if nothing is found or configured.