-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Provide a supported API #12
Comments
So the things I needed from Towncrier in the past, of the top of my head, were:
But rather than exposing an API endpoint each time it's necessary, I suggest having an architecture that allows having API (almost) always exposed by having a separate layer that the CLI would use. This way, the main consumer of that API would be the CLI, and everything that CLI offers would be available automatically: [CLI] -> [public API] -> [private APIs in the project core]
^
|
/----------------\
| other projects |
| importing scriv |
\----------------/ This would probably mean moving logic from click-decorated functions into separate ones. |
I'm coming back to thinking about this. I don't understand this one:
The fragments are just files in a directory. Do you mean, figure out what fragments are present? |
I've refactored to create a sketch of an API in pull request #28. Take a look and let me know what you think. |
Yes, even better: check if the fragments are present and valid. In the context of linting checks in pull requests, it's usually important to figure out if a new fragment has been added, not that some files are present in the dir (they can be old). |
Thanks. I've written a new issue for that feature: Provide a "check" command. |
Version 0.11.0 has an (undocumented) API now. Let me know if you try it. |
From https://twitter.com/webKnjaZ/status/1308027546697641984
The text was updated successfully, but these errors were encountered: