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

refactor(spm): initial refactor of internals to work with new API #114

Merged
merged 20 commits into from
Jan 13, 2025

Conversation

nfrasser
Copy link
Member

@nfrasser nfrasser commented Dec 31, 2024

  • Replace CryoSPARC.cli, .vis, .rtp with single .api key
  • Update implementation of all controller functions to use API
  • Additional stream methods for convenience
  • Strategy for mock client in tests

@nfrasser nfrasser self-assigned this Dec 31, 2024
Copy link

vercel bot commented Dec 31, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
cryosparc-tools ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 10, 2025 10:30pm

cryosparc/api.pyi Outdated Show resolved Hide resolved

if TYPE_CHECKING:
from numpy.typing import DTypeLike, NDArray

Shape = Tuple[int, ...]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to spec.py to avoid unnecessarily importing the native core module when only these simple types are required.

cryosparc/model_registry.py Outdated Show resolved Hide resolved
@nfrasser nfrasser marked this pull request as ready for review January 4, 2025 00:19
@nfrasser
Copy link
Member Author

nfrasser commented Jan 4, 2025

I haven't yet completed a full end-to-end tests (re-run the example notebooks) will the real API running, some more changes may come if I find any issues with that. Otherwise the core migration has been completed.

cryosparc/api.py Outdated Show resolved Hide resolved
cryosparc/api.py Show resolved Hide resolved
cryosparc/job.py Outdated Show resolved Hide resolved
cryosparc/job.py Outdated Show resolved Hide resolved
cryosparc/job.py Outdated Show resolved Hide resolved
cryosparc/job.py Show resolved Hide resolved
cryosparc/job.py Outdated Show resolved Hide resolved
cryosparc/tools.py Outdated Show resolved Hide resolved
cryosparc/tools.py Outdated Show resolved Hide resolved
cryosparc/tools.py Outdated Show resolved Hide resolved
@Puratinamu
Copy link
Contributor

Puratinamu commented Jan 6, 2025

what do you think about adding dataset/ and controller/ as new folders under cryosparc/? The two seem to be more well defined now and having this distinction could help with separation of concerns

Interface remains largely the same, with some deprecations and changes to return values for asset endpoints
Mocks client functions rather than API requests. This is not the greatest, but mocking the HTTP requests would have been way more complicated
@nfrasser
Copy link
Member Author

nfrasser commented Jan 7, 2025

what do you think about adding dataset/ and controller/ as new folders under cryosparc/? The two seem to be more well defined now and having this distinction could help with separation of concerns

@Puratinamu will do for controllers, but how would you do this for datasets?

Something like this?:

dataset.py -> dataset/__init__.py
column.py  -> dataset/column.py
row.py     -> dataset/row.py
dtype.py   -> dataset/dtype.py
core.pyx   -> dataset/core.pyx

cryosparc/job.py Outdated Show resolved Hide resolved
@Puratinamu
Copy link
Contributor

what do you think about adding dataset/ and controller/ as new folders under cryosparc/? The two seem to be more well defined now and having this distinction could help with separation of concerns

@Puratinamu will do for controllers, but how would you do this for datasets?

Something like this?:

dataset.py -> dataset/__init__.py
column.py  -> dataset/column.py
row.py     -> dataset/row.py
dtype.py   -> dataset/dtype.py
core.pyx   -> dataset/core.pyx

That sounds good.

@@ -1,5 +1,37 @@
# Changelog

## Next
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed with Rich , all of these are OK as long as they're well documented

@nfrasser
Copy link
Member Author

nfrasser commented Jan 9, 2025

Ready for another round of review, might have to do another look over the docs closer to deployment to ensure they're still accurate.

Copy link
Contributor

@Puratinamu Puratinamu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, few more small things

@@ -83,25 +87,24 @@ class CryoSPARC:
``base_port + 5`` should be accessible on the network.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do the port numbers mentioned here have to change with the port number shuffling in SPM?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, will reword

Comment on lines +601 to +602
# TODO: limit find to one workspace
workspaces = self.api.workspaces.find(project_uid=[project_uid], order=-1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this TODO not implemented?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The find endpoint doesn't currently accept a limit argument, none of the find endpoints do. They definitely should, but as a larger pagination task.

if workspace_uid is None:
# TODO: limit find to one workspace
workspaces = self.api.workspaces.find(project_uid=[project_uid], order=-1)
workspace = workspaces[0] if workspaces else self.api.workspaces.create(project_uid, title=title)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes the title of the workspace the same as the title of the output? Maybe it should be something more generic like "Tools Workspace for <title>"? similarly for the job

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We just need some title in a rare case like this, and I'd prefer not to make up a naming convention like this in English - imagining a scenario where someone in Germany records all their project and workspace titles in German, but suddenly sees "Tools Workspace for Ergebnisse der Datenanalyse" or something like that. I know we already do this in some places, but I'd like to minimize this if we don't have to.

@nfrasser nfrasser merged commit 5c2fc96 into spm Jan 13, 2025
11 checks passed
@nfrasser nfrasser deleted the nick/spm/tools-integration branch January 13, 2025 19:41
nfrasser added a commit that referenced this pull request Jan 13, 2025
Move everything relevant into submodules, as per review feedback at #114 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants