Idea: create another repo/package with OS-specific syncers

Problem 1

rsync isn't always installed on all hosts. For example, Windows. Or institutional hosting that intentionally or unintentionally opted out of installing it. Or a slim Docker image.

Problem 2

To address problem 1, Composer Stager also includes a PhpFileSyncer that syncs directories entirely with PHP code, but that turns out to be more complex and challenging than we initially thought. Especially when it comes to ensuring directory and file permissions and other attributes are synced correctly.

Proposal

Remove PhpFileSyncer, and instead if/when people need to use Composer Stager without rsync, we create a separate repo with syncers that use the following commands, depending on OS:

For Windows, robocopy, which has options for mirroring (deleting files in the destination that aren't in the source), specifying exclusions, and preserving attributes.
For Linux, cp, whose -a option preserves attributes. While it doesn't have its own support for exclusions, we can use bash's extglob to achieve it, but a negation glob only supports processing one negation path component at a time. So we'd need something like the following:
```
# If we want to exclude "sites/default":
shopt -s extglob
cp -a source/!(sites) dest/
cp -a --parents source/sites/!(default) dest/
```
However, Linux's cp also doesn't support deleting files from the destination that aren't in the source. So a CpFileSyncer would need to add some additional logic on top of running the cp commands for that. I'm pretty confident that that could be implemented with a few relatively straightforward shell commands.
For Mac, although MacOS has a cp command, it works differently than on Linux and doesn't support the --parents option which would be needed to handle deep exclusions. However, Mac has the ditto command, which lets you specify a destination path pattern containing directories that don't exist yet, and ditto will make them if they're needed, so the above example could be done like this:
```
# If we want to exclude "sites/default":
shopt -s extglob
ditto source/!(sites) dest/
ditto source/sites/!(default) dest/sites/
```

We don't necessarily need to implement these syncers yet. I just wanted to write this up to make the claim that it's possible, and would likely not be much code, and then we can rely on the OS to handle the hard stuff like preserving attributes, and therefore, I think it's reasonable for us to remove the PhpFileSyncer.

I just wanted to write this up to make the claim that it's possible, and would likely not be much code, and then we can rely on the OS to handle the hard stuff

I just want to point out that I also think we thought the PHP file syncer was not going to be much work and we could rely on the Symfony File System which we ended not being able to.

I hope that we can first try extremely hard to reduce the amount of code that we have to write and maintain. Here is my proposal:

Release Composer Stager with only rsync support.
Move the current PHP file syncer into a new WindowsSyncer package. This package should validate that is only ever used on the Window OS. From my understanding from @TravisCarden the current permission problems of the PHP file syncer do not affect windows.

Using our existing work for WindowsSyncer package does not mean that this is how the package will work internally forever. We should be able to switch it to robocopy later without any changes for the users of the package. If we plan to switch it later we could even validate the existence of robocopyin the first version even if we don't use it to make sure all users can switch.

This will mean that everyone except Windows users will be required to have rsynce(Windows users also could install rsync). I think this is ok because:

We don't know how much overlap there is between the users who don't have rsync and the users who are interested in using AutoUpdates in Drupal
We don't know how hard it will be for those users to install rsync
We don't know how many people that would be stopped by 1) and 2) would have been stopped anyway by the need to have the Composer executable, the need to have proc_open or any other requirement we have for the system.

I know Composer Stager is a separate package from Drupal but currently I don't know that there is any significant interest or contribution from anyone outside of those working on this project to support Automatic Updates in Drupal.

We can conjecture that there will be many sites that fall in 1) or that 2) will be very hard or 3) won't have stopped them anyways, but can't really know this. It is very likely any code we write we will maintain for a very long time, and that the code will be more complicated than we first predict. Because Composer Stager, first major usage will probably be in the experimental phase as part of AutoUpdates in Drupal core I think we should try to use that phase to determine what the actual need is for non-Windows sites without rsync. Then we should determine if the need is great enough to take on this extra work to create and maintain these packages in the long term.

Obviously this will leave some people out but right now we don't know how many people that will be, so it is hard to judge is the extra work to not leave them out is worth it. We wouldn't be making the decision to leave them out of the eventual AutoUpdates module just its first experimental(hopefully Alpha) version.

php-tuf / composer-stager