Create separate package for importing the terminal/driver in custom extensions

[R-Bower]

Is your feature request related to a problem? Please describe.
I'm building a vscode extension that uses bitbake over the CLI (just bash for now). Your PseudoTerminal and driver approach is awesome, and I could see our project benefitting from this.

Describe the solution you'd like
It'd be great if we could source the BitBake Driver and Terminal modules independently like a typical npm dependency.

Describe alternatives you've considered
Forking the existing code from the library and integrating as needed.

Additional context
I'd be happy to submit a PR with this change, though it may require some restructuring, re: packages. I believe this repository is set up primarily as a single extension. I'd probably extract the reusable logic into a shared package for external consumption.

[deribaucourt]

Hello,

Turning the BitbakeDriver into a library would be very useful indeed. This could allow us to run it in the VIM npm server language package to port more features there.
There are some bits of code that currently tie it to VSCode specific libraries like the clientNotificationManager. The associated features should not be removed, but I think we could factorize them differently to a have a base BitbakeDriver that is npm-agnostic, and another class VSCode specific. We already have a sub-library package. Maybe that would be the appropriate place to move it. We currently don't publish that one, but it could be set-up. We have automated publishing for the sub-package for the server language to npm.

I thought the Terminal was more tailored for VSCode presentation. Which parts would you consider using externally?

If you are building a separate extension, it's definitely interesting if you can reuse the Driver approach. However it also requires configuration and an icon and so forth. Maybe what you could find helpful is rather a communication API to ask our extension to run your commands and give you the output. I guess the Commands API could allow this. This would unify the configuration management of the two extensions, but you'd have to use ours as a dependency.

Maybe the feature you want to develop could fit into this extension? Feature contributions are also welcome 😄

[R-Bower]

I thought the Terminal was more tailored for VSCode presentation. Which parts would you consider using externally?

It's actually the terminal that we're looking for, functionality-wise. Although it seems simple enough to copy/paste. We may even need to customize it further.

Turning the BitbakeDriver into a library would be very useful indeed. This could allow us to run it in the VIM npm server language package to port more features there. We already have a sub-library package. Maybe that would be the appropriate place to move it.

There are some bits of code that currently tie it to VSCode specific libraries like the clientNotificationManager. The associated features should not be removed, but I think we could factorize them differently to a have a base BitbakeDriver that is npm-agnostic, and another class VSCode specific.

This might call for two separate libraries. Maybe a vscode-bitbake-lib for the vscode-specific stuff. Then we could do a bitbake-node library for npm-agnostic (i.e. not VSCode specific) library. The vscode-bitbake-lib could have a dependency on the bitbake-node as needed.

Maybe what you could find helpful is rather a communication API to ask our extension to run your commands and give you the output.

This could also work, but I wouldn't mind adding support for both approaches.

[deribaucourt]

I would prefer to avoid having two distinct mechanisms to make our terminals implementation shared to other extensions. I believe the Commands API is the best approach since it will avoid duplicating the settings management, terminal theming declarations in package.json and more...

There are already a command allowing to run arbitrary tasks: bitbake.run-task. I guess you will also need their terminal output? In which case it should be possible to return it with finishProcessExecution() (hoping it doesn't freeze other features, we'll have to check on that). You could then run it externally with vscode.commands.executeCommand().

If you need to run more custom commands (devtools, oe-pkgdata-utils, poky/scripts, ...), then we can create an additional hidden command for that. However since it allows to run arbitrary shell commands, we'll need to put a few sanitization rules in place:

• Removing special characters with sanitizeForShell()
• Only allow running commands that could be related to BitBake, or set-up Workspace Trust before running anything

Once complete, we can document this API in the README-DEVELOPER.md.

Out of curiosity, what kind of feature are you going to develop in your extension? Do you plan to make it opensource?