Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python Bindings v0.1.0 (WIP) #311

Closed
4 tasks done
baszalmstra opened this issue Sep 5, 2023 · 4 comments
Closed
4 tasks done

Python Bindings v0.1.0 (WIP) #311

baszalmstra opened this issue Sep 5, 2023 · 4 comments

Comments

@baszalmstra
Copy link
Collaborator

baszalmstra commented Sep 5, 2023

With #279 we have the first implementation of python bindings for rattler. 🎉

For v0.1.0 of the bindings we would like to be able to achieve the following goal:

🥅 You can solve and install an environment using the Python bindings.

We want to be able to do this to make it easier for users coming from Python to start using rattler as their base library for everything conda instead of having to rely on conda or mamba.

To that end, the following code needs to be worked on:

  • You can fetch repodata from a remote or local channel.
    • The main entry point is: fetch_repo_data.
    • We have to determine how we will manage memory. Since RepoData takes up a significant amount of memory we want to reduce copying, duplication, etc. The solver also takes PackageRecords by reference how do we deal with that?
    • We will have to investigate how to handle async
    • We need bindings for the following types:
    • fetch_repo_data returns an object that uses a scope to drop a lock. How do we deal with that?
    • Out of scope for now is:
      • the new Gateway implementation unless this lands pretty soon (would simplify the whole API a lot). Might be worth putting some effort in?
      • Download callback is not a requirement but would be nice to have.
  • Pass RepodataRecord or PackageRecord to a solver function to solve the environment.
  • Install an environment from a list of RepodataRecords.
@wolfv
Copy link
Contributor

wolfv commented Sep 6, 2023

I am not sure I understand why we need RepodataRecord and friends. We could also decide to hide all that behind the API, right? And just have a "Repodata" object that holds the deserialized repodata?

@baszalmstra
Copy link
Collaborator Author

Yeah I like the idea of a higher level api. But would the repodata hold all records or a selection?

@Wackyator
Copy link
Contributor

AuthenticatedClient, RepoDataRecord, PackageRecord, fetch_repo_data are added now, maybe we should update this a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants