Discussion: extending the Manager Interfaces

[jjjermiah]

I've played around with implementing the interfaces for both Package Manager and Environment Manager for pixi, and wanted to start a discussion on a few points from this perspective. Hope this is the right place for now as I proceed with development

[karthiknadig]

Let’s us know what you have in mind.

[jjjermiah]

1. pixi's design of an environment being composed of multiple features to which packages belong to, both pypi and conda

   • with this in mind, its most useful to let user choose which feature to add to

     Current mechanism of adding packages through the pixi extension

     current implementation through the pixi-vscode's activation point

     

   • is there a plan for design where i could contribute the actual flow after a user chooses to install package?

2. I understand the 'common_packages' is pypi-specific, and though this might be out of the scope of this project, a nice-to-have would be a couple other optional interfaces:

   • instead of the default quickpick for packages, allowing for a custom quickpick to plug-in during the select packages
     • this would also allow streaming of similar packages on the fly by querying different indexes/apis (this is what was done in the gif above, though has some hiccups with speed)
     • also pixi allows users to install from either pypi or conda channels, so a intermediate step between 'install custom package' and actual choosing of the packages, would be letting them decide which source

3. By Pixi's design, a manifest-file/project can define any number of environments, with at least one called default, and if users have some "standard" template of projects, they might be very similar in the environment names/features, etc.

   • thus, the environment view can be a bit cluttered, especially with larger projects
   Env Manager With Multi-Folder workspace

   

   • I dont really have a good solution for this
   • first thought is extending the TreeProvider currently implemented, and allowing for an extra level of nesting under Pixi and before listing the environments to separate the environments

[jjjermiah]

I think I could also use some clarification on how the Project <-> Environment relationships work

By design (for now), pixi allows for

1. project-level environments
2. global environments

If a user creates a new project with this extension, can/should the contributing extension limit the scope of valid environments (only those defined within that project)?

[karthiknadig]

For 1 & 2,

Have you tried implementing the getInstallable . Currently, it might be a "hack" to use that to expose potential options, but, we can improve that API to better fit the scenario.

we are open to suggestions on improving this. The "hack" right now would be to return two options like pypi and conda. This will change the install flow a bit, and you should be able to pick up from there. I will think about ways if this can be improved to provide entry points to different flows, rather that selections for installations.

For 3

Can you use the displayName to include project name as a prefix or suffix? The API, preserves the sorting that you provide so you could keep all the environments that belong to a project grouped.

Project <-> Environment UI

The environments' view is intended to show all (global and project). You could add a command to toggle filtering the global ones. Essentially filtering the getEnvironments result to only include the ones that users might want (this could be the default experience). While using a toggle provides a way to easily get all environments if users want. ( I need to check if this is possible, but you should be able to place a button on the pixi manager, to toggle it from that UI.)

[karthiknadig]

Created:
improve context for the tree view item: #94
Add group support for the environment view: #95

[jjjermiah]

thanks for the quick response!

• I definitely misunderstood getInstallable, will give it a try
• I thought about displayName being prefixed with (<project environment is from>), which is probably a sufficient hack for now

user-configuration for which types of envs to display is probably a good solution for now as well.

will keep experimenting

[karthiknadig]

With the latest release I remove the getInstallable API, but now, calling install with give you full control of the experience. You can look at the venv (built-in) and conda (demo) implementations for examples. This should address concerns 1 and 2.

For 3, now you can provide a group for environment, and each group UI element had context that can be use to provide custom commands. Please give it a try.

Closing this, for now, please let me know if you have any additional asks or concerns.

[jjjermiah]

thank you @karthiknadig havent had a chance to work on this yet but will be soon.