search

NASA-PDS / pds-api-client

Python library and API for accessing the online PDS Search API. This repository however only contains the utilities used to generate, test, document and demo the actual pds.api-client package. The library itself is only released on pypi (https://pypi.org/project/pds.api-client/) but not here on github
https://nasa-pds.github.io/pds-api-client/
Apache License 2.0
0 stars 1 forks source link

No setup.py and pypi release workflow #3

Open michaelaye opened 3 years ago

michaelaye commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

michaelaye commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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