bomoko
commented
1 year ago Hi @AlexSkrypnyk
Thanks for opening up this discussion. Yeah, this is something we've discussed a lot internally.
I think the general consensus is that they'll be merged once we do a Lagoon cli rework, which shouldn't be too far off.
For completeness, I'll just mention the one major pro of having it as a separate binary - particularly if we slim it down to not include, say, the bundled rsync binary. Basically, if you favor the so-called unix philosophy, having it as a separate tool makes sense aesthetically - and, moreover, there's a way in which the two tools target different classes of use - where the cli is a general tool for mostly interacting with the lagoon api outside of a lagoon environment, lagoon-sync is currently a tool that runs inside of a lagoon environment (which makes it a good candidate for, say, shipping with the lagoon commons image in a way that, arguably, isn't the case with the lagoon-cli).
However, I think we're all in agreement that aside from the above, it makes sense to merge it into the cli.
Can we please use this issue to discuss cons and pros of running this binary as a standalone project vs merging it with a LagoonCLI project
LagoonCLI is already used by many users and systems to perform required tasks. Having the functionality that this package provides within LagoonCLI is something I would expect, because similar tools from other providers (Acquia, Pantheon etc) have this as a part of their cli toolkit.
Also, asking users to install a second binary feels a bit too much.
Mind that there are external tools like DDev that want to integrate with Lagoon, and they would have to use this binary and lagooncli; and then they will have to manage issues caused by different versions of the binaries.