search

nih-sparc / sparc.client

Python client for NIH SPARC
https://docs.sparc.science/docs/sparc-python-client
Apache License 2.0
0 stars 8 forks source link

add osparc-tutorial #21

Closed bisgaard-itis closed 1 year ago

bisgaard-itis commented 1 year ago

This adds a jupyter notebook osparc tutorial to the repo. A markdown version of this notebook will also be added to the Readme documentation

hsorby commented 1 year ago

I find that there is a lot of variability in the naming for o2S2parc, but at least the use is consistent by domain. The website is osparc, in code it is common to see o2sparc or O2SparcService, and in the text we see o2S2parc. I was just wondering if people think this is fine and keep it like it is or if we should try and move to a consistent name across all domains.

bisgaard-itis commented 1 year ago

I find that there is a lot of variability in the naming for o2S2parc, but at least the use is consistent by domain. The website is osparc, in code it is common to see o2sparc or O2SparcService, and in the text we see o2S2parc. I was just wondering if people think this is fine and keep it like it is or if we should try and move to a consistent name across all domains.

That's a good point! Thanks a lot for the feedback. I will take up the discussion on our side. I believe the name o²S²PARC is settled, so probably we cannot change that. But having a consistent way to denote that service/platform in code would be a good thing I think.

bisgaard-itis commented 1 year ago

I find that there is a lot of variability in the naming for o2S2parc, but at least the use is consistent by domain. The website is osparc, in code it is common to see o2sparc or O2SparcService, and in the text we see o2S2parc. I was just wondering if people think this is fine and keep it like it is or if we should try and move to a consistent name across all domains.

That's a good point! Thanks a lot for the feedback. I will take up the discussion on our side. I believe the name o²S²PARC is settled, so probably we cannot change that. But having a consistent way to denote that service/platform in code would be a good thing I think.

@hsorby I had another look and I think the naming conventions make sense to the extend that they are consistent. The correct name is "o²S²PARC", but of course we don't want to use that name for variables in the code. We have our "own" client which is called osparc and then we call the "subclient" of the sparc.client o2sparc to not have name clashes with osparc. I think that makes sense and as far as I can tell we are consistent with these names in the tutorial.