[ENH] - Move end user API interactions into the package

[kcpevey]

Feature description

I've gotten many requests for interacting with conda-store on Nebari via an API. I think everything that I'd find useful is contained inside of https://github.com/conda-incubator/conda-store/blob/524a1cc7313f3eca0d63d096ffc478df344b88ea/conda-store-server/tests/user_journeys/utils/api_utils.py . However, since its not part of the package, I can't use it directly.

I propose to move this little API into the package itself so that end users can make use of it.

Value and/or benefit

This would add the ability to programmatically interact with conda-store without rewrite REST interactions all the time.

Anything else?

No response

[trallard]

This is part of a broader discussion about providing complete symmetry between conda-store variants, API, CLI, etc. Of course that would be a larger lift/effort, but it is the only way to address also feedback raised through the user research studies. And I would certainly prefer this over ad hoc addition of methods.

I think everything that I'd find useful is contained inside of 524a1cc/conda-store-server/tests/user_journeys/utils/api_utils.py

Can you provide more concrete examples of what this programmatic access means/would look like?

[kcpevey]

I was pointed to the api_utils.py when I asked about a python api, but I didn't realize that a python api already existed - https://github.com/conda-incubator/conda-store/blob/main/conda-store/conda_store/api.py . I understand that we don't encourage usage of this api until the api/cli symmetry effort is complete. That feels like a separate issue, and its fine to close this in favor of another, more appropriate issue.

To answer your question:

Can you provide more concrete examples of what this programmatic access means/would look like?

As a software engineer who maintains many environments for other team members (on nebari), I often have to push updates to all my environments. While conda-store has its own "version history", software projects generally keep their history in git repositories. Typical usecases of conda-store for me are to have a git repo which holds an environment file (which is used to run ci tests). Any changes to my environment file in the repo then have to be hand-copied over to conda-store through the UI and rebuilt. I'd love to build up some code which could do this process for me.

For the conda-store bit, this covers the vast majority:

api = API(base_url=base_url, token=token)
# create environment 
api.create_environment(namespace, specification_path)

If there is a current, recommended approach to this, I'd love to learn about it.

[peytondmurray]

Currently we are working on a number of user workflows. The REST API and python API will change to meet these user needs moving. Let's revisit this once this effort starts getting pushed forward.