You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The model is one thing. But we would also need functions to call the endpoints.
I'm not entirely sure yet what the scope of Scitacean is. I did not plan for it to cover the whole API but instead focus on the most commonly used (by non-experts) operations. What would be the benefit for you to handle proposals with Scitacean instead of PySciCat?
I had a quick stab at it. Adding the model to the generator and writing the functions to call the endpoints is easy. But the proposal models have fields with non standard naming schemes:
pi_email, pi_firstname, pi_lastname
MeasurementPeriodList
They cause problems for the automated name translation because that assumes camelCase and breaks for snake_case and PascalCase. This can be fixed but probably needs special case handling for proposals.
Most scicat models are implemented, but
Proposal
seems to be missing.This would be handy for implementing proposal ingesters and for getting e.g. the abstract of the proposal.
The text was updated successfully, but these errors were encountered: