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

Being more explicit with documenting public API #2235

Open
fridex opened this issue Dec 19, 2022 · 2 comments
Open

Being more explicit with documenting public API #2235

fridex opened this issue Dec 19, 2022 · 2 comments

Comments

@fridex
Copy link
Contributor

fridex commented Dec 19, 2022

Description of issue or feature request:

As a result of discussion in #2234, opening this issue to make consensus on eventually declaring public API directly in Python sources.

Current behavior:

Developers can explore API provided by python-tuf using RTD pages. As per PEP-8 standard, __all__ could be considered to declare public API. Note by doing so, this also affects start imports.

Expected behavior:

Identify possible use-cases for declaring public API in Python sources.

@jku
Copy link
Member

jku commented Dec 19, 2022

I'll leave some comments for ngclient since I think that's the easy case:

  • I'm pretty happy with what is in tuf/ngclient/__init__.py: that really defines the public ngclient API. Defining __all__ sounds good to me -- but not sure if it changes anything from default? Maybe defining __all__ even if it is same as default is good practice? 🤷
  • in hindsight, all of the sub modules could have been internal (so updater.py could be _updater.py or _internal/updater.py)
    • If we did that, probably the only required addition to __init__.py might be a import TargetFile (because the updater API exposes it so makes sense to make it available)
    • This would be an API change but likely not a problematic one

I think the ngclient changes sound reasonable (not strictly necessary but result would likely be better software)

@fridex
Copy link
Contributor Author

fridex commented Jan 26, 2023

See also #2234 (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

No branches or pull requests

2 participants