Add contribution points to extension API to add external support for Rye, pixi etc

[mitsuhiko]

This is not an issue I really wanted to open, because I was hoping I can avoid putting yet another thing into the ecosystem that requires custom handling. Unfortunately vscode currently installs tools itself (eg: black etc.) directly in this extension. Rye does not place pip in the virtualenv and requires you to install tools via other means.

Thus for Rye to work well, unfortunately it looks like this extension would have to be expanded.

• a rye based module installed which invokes rye add --dev package-name followed by rye sync
• optionally a config key which uses rye tools install package-name (globally instead?)
• hooks to lint/format that directly uses rye lint and rye fmt which directly pass through to ruff which it bundles

I'm not at all happy that this might mean adding another tool to the list of things that this extension needs to maintain, so I'm open to alternatives. One thought that I had as to add hidden pip support to rye but unfortunately this breaks a lot of stuff. While I can make a fake pip command available that just internally calls rye add, the module check also requires that the pip module in installed which I don't want to do. It would make it impossible for a user to actually install pip if they need it.

I'm also not sure how much interest there is at this point for Rye support in vscode, so maybe that issue can also act as a way to track interest.

Relates to https://github.com/mitsuhiko/rye/issues/556

[baszalmstra]

We have the same problem with pixi.

Would it help if the registerEnvironmentProvider as suggested in Environment API would be available and modified to support this usecase e.g. adding additional packages to a custom environment?

It at least sounds like something I would wanna use for pixi as well.

[brettcannon]

We are starting to discuss the idea of a workflow API that would allow extensions to provide contribution points that we delegate to when available. That way we can provide a default experience that can be overridden as appropriate by other workflow tools (it would also mean we would pull out our own support for anything that isn't pip + venv into separate extensions). So this is an issue we are thinking about how to solve.

@baszalmstra FYI I've already talked to Wolf about this idea.