CLI, Extension <> mirrord-layer interface

[aviramha]

This is related to the next version of mirrord, that will use the mirrord-layer component.
There are two ways we can intergrate with mirrord-layer:

Shared CLI

The CLI will receive arguments, execute the process with mirrord-layer loaded using LD_PRELOAD/DYLD_INSERT_LIBRARIES. The extensions (JetBrains, VSCode) will use the cli.

Pros

• More reusable code - a change in the cli, as long as it keeps the same interface doesn't require change in extensions.

Cons

• It might cause weird stuff when debugging using the IDE (it should work, but still)

Direct use of mirrord-layer

The CLI will work pretty much the same as before. The extensions wont use the cli, but will just execute the process by themselves, loading it also using LD_PRELOAD/DYLD_INSERT_LIBRARIES

Pros

• We can maximize UX/DX in each extension, implementing & customizing the behavior to be perfect in each scenario.
• Debugging using IDE will most probably work
• We can try doing other tricks to load other than LD_PRELOAD/DYLD_INSERT_LIBRARIES (leveraging the IDE apis?)

Cons

• More code to maintain

[meowjesty]

I'm in favor of using a cli.

We can maximize UX/DX in each extension, implementing & customizing the behavior to be perfect in each scenario.

I don't have much experience with extension development, so I'm not sure how big of a benefit this would be, versus the increase in code.

We can try doing other tricks to load other than LD_PRELOAD/DYLD_INSERT_LIBRARIES (leveraging the IDE apis?)

Do you think we need more ways to load? I can see us revisiting this in the future, but right now I feel these solutions are adequate.

[aviramha]

Update - we decided for the first versions of the extension to use layer directly, as using the cli in the extension would require more development (adding an env var to a process before launching it is easier than replacing the runtime binary)