No setup.py and pypi release workflow

[michaelaye]

If you store your pypi.org access token as a secret in the GH settings, I can use it (even without knowing its content) to create a pypi release workflow and a setup.py for you. I just need to know the name of the variable you store it as in the settings.
Nice work on the alpha!

[tloubrieu-jpl]

Hi @michaelaye , thanks for your feedback.

The code generation and deployment workflow is described in this file https://github.com/NASA-PDS/pds-api-client/blob/master/README_GENERATE.md . This is not in the README.md as usual since this file is re-created by the openapi generator that is used to generate the code of the API client.

Per you releasing of the code on pypi, we are usually rather working on development collaboration through pull request. Which means you can update the code as you like including testing the release on pypi test with your own login and then do a pull request that we can merge into the main branch of the code. Does that make sense ?

Let me know if that answers your question ?

Thanks again

[tloubrieu-jpl]

@michaelaye note that the setup.py is also generated by the code generation process.

[michaelaye]

Per you releasing of the code on pypi, we are usually rather working on development collaboration through pull request. Which means you can update the code as you like including testing the release on pypi test with your own login and then do a pull request that we can merge into the main branch of the code. Does that make sense ?

GH PRs are the obvious mode of collaboration, but I can not test uploading to pypi as I do not own the pypi-package pds.api-client.

[michaelaye]

@michaelaye note that the setup.py is also generated by the code generation process.

ok, i forgot about that. then i can at least install locally. hmm, i'm not sure it's the best way to store the api client unexpressed in the repo, as the generation process has several parameters that could create slightly different clients? I think it would be best to have a complete client with setup.py stored in the repo, so that pip installs that point to the GH repo using the git+https protocol also work directly?

[michaelaye]

in other words, we shouldn't have the end user running the swagger stuff, but i guess in between devs, it just might work.
Later, we (at planetarypy i guess?) could be scripting this anyway when we generate a nice wrapper for everyone.

[jordanpadams]

@michaelaye 100% agree. @tloubrieu-jpl were just talking about this and we need to plan this out in a little more detail about the wrapper library for the base API client. the auto-generated client does not provide the additional "features" and shortcuts people will want in order to enable a more useful user experience.

[michaelaye]

ah, you are also planning to wrap the auto-generated API client into something more?
Wouldn't you run very fast into instrument-specific idiosyncrasies with special cases? I am currently thinking those kinds of special treatment would be better in an instrument-specific sub-package of planetarypy-core.
Unless you are thinking of just another thin layer on top of the auto-generated one to expose more functionality than the OpenAPI process allows?
Maybe at some point we should design a dependency flow diagram that shows how all things are connected...

[jordanpadams]

@michaelaye

ah, you are also planning to wrap the auto-generated API client into something more?
Wouldn't you run very fast into instrument-specific idiosyncrasies with special cases? I am currently thinking those kinds of special treatment would be better in an instrument-specific sub-package of planetarypy-core.

quite possibly. we have not dug into the planetarypy repo too deeply, but implementing the wrapper there may make a lot of sense. in the end, we were really just going to implement some base or "core" use cases as helper functions for easier access to the API. and then we would allow for all those idiosyncrasies to be coded by the community (and merged into the repo, of course).

Unless you are thinking of just another thin layer on top of the auto-generated one to expose more functionality than the OpenAPI process allows?
Maybe at some point we should design a dependency flow diagram that shows how all things are connected...

totally agree. this is probably 6-months out or so as we would like to get a fairly robust baseline for the API v1.0 before we move too far ahead on the wrapper client. but when we do, planetarypy will definitely be involved in a trade study to determine if we should develop a separate thin layer to access the PDS API, or integrate directly into planetarypy