-
Notifications
You must be signed in to change notification settings - Fork 12
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
Formalize public vs private API rule #613
Comments
This rule is indeed straightforward - it makes complete sense to me. |
I like the rule. Same reasoning as @adswa: "straightforward". |
Thanks for the feedback. I looked into what this would mean (using something like This reveal a bunch of questions. Should we apply this rule uniformly to all sub-packages (or even sub-directories)? I'd be in favor of that, for simplicity. I am inclined to make an exception for With that in mind, here are to chunks of rule-violations we would have in the current code base: Test tooling imports not from
|
I propose the following addition to the toplevel README: diff --git a/README.md b/README.md
index dc020d7..00f6c36 100644
--- a/README.md
+++ b/README.md
@@ -142,6 +142,33 @@ this extension causes a range of patches to be applied to the `datalad` package
to enable them. A comprehensive description of the current set of patch is
available at http://docs.datalad.org/projects/next/en/latest/#datalad-patches
+## Developing with DataLad NEXT
+
+This extension package moves fast in comparison to the core package. Nevertheless,
+attention is paid to API stability, adequate semantic versioning, and informative
+changelogs.
+
+### Public vs internal API
+
+Anything that can be imported directly from any of the sub-packages in
+`datalad_next` is considered to be part of the public API. Changes to this API
+determine the versioning, and development is done with the aim to keep this API
+as stable as possible. This includes signatures and return value behavior.
+
+As an example: `from datalad_next.runners import iter_git_subproc` imports a
+part of the public API, but `from datalad_next.runners.git import
+iter_git_subproc` does not.
+
+### Use of the internal API
+
+Developers can obviously use parts of the non-public API. However, this should
+only be done with the understanding that these components may change from one
+release to another, with no guarantee of transition periods, deprecation
+warnings, etc.
+
+Developers are adviced to never reuse any components with names starting with
+`_` (underscore). Their use should be limited to their individual subpackage.
+
## Acknowledgements
This DataLad extension was developed with funding from the Deutsche |
Reads well to me 👍 |
This implements the plan declared at datalad#613 (comment) A dedicated list of components is exposed at the package's top-level, and only that. All other functionality and imports have been move to package-internal files. All other, now undesired, top-level imports have been annotated and scheduled for removal with the v2.0 release.
This implements the plan declared at datalad#613 (comment) A dedicated list of components is exposed at the package's top-level, and only that. All other functionality and imports have been move to package-internal files. All other, now undesired, top-level imports have been annotated and scheduled for removal with the v2.0 release.
This implements the plan declared at datalad#613 (comment) A dedicated list of components is exposed at the package's top-level, and only that. All other functionality and imports have been move to package-internal files. All other, now undesired, top-level imports have been annotated and scheduled for removal with the v2.0 release.
This implements the plan declared at datalad#613 (comment) A dedicated list of components is exposed at the package's top-level, and only that. All other functionality and imports have been move to package-internal files. All other, now undesired, top-level imports have been annotated and scheduled for removal with the v2.0 release.
This pretty much takes the role of `datalad_next.tests.utils`. The new setup treats `tests` like any other sub-package and exposes reusable tools as a public API at the top-level. In doing so, `SkipTest` was made obsolete and excluded from that API. The usage of `rmtree` is altered to import from `datalad_next.utils`. datalad#613
This pretty much takes the role of `datalad_next.tests.utils`. The new setup treats `tests` like any other sub-package and exposes reusable tools as a public API at the top-level. In doing so, `SkipTest` was made obsolete and excluded from that API. The usage of `rmtree` is altered to import from `datalad_next.utils`. For the first time, test tooling helpers have their documentation rendered too. datalad#613
This pretty much takes the role of `datalad_next.tests.utils`. The new setup treats `tests` like any other sub-package and exposes reusable tools as a public API at the top-level. In doing so, `SkipTest` was made obsolete and excluded from that API. The usage of `rmtree` is altered to import from `datalad_next.utils`. For the first time, test tooling helpers have their documentation rendered too. datalad#613
This continues the work done for datalad#613. Now all relevant symbols are directly documented, for every top-level package. In doing so, I added a first set of markers to shape the API streamlining that will come with v2.0. Ping datalad#624 Ping datalad#616 Some implementations that continued to be located in `__init__.py` files have been move into new, dedicated source files.
This has been a frequent discussion topic. We need a simple rule for people to tell if something is meant to be public or part of an internal API.
Right now the contributing guide says:
I would propose to establish a rule that anything that cannot be imported from a subpackages
__init__.py
is not considered part of the public API.This rule is simple.
The one counter argument that I can think of it: There might be pieces that are more special (within in particular subpackage), for example, heavy-ish runtime deps that should not force unconditional imports. If that is the case, it might be worth to:
a) consider moving that code into its own subpackage (if it already has a different dependency set)
b) consider importing within "runtime" code (ie. within a function body)
while otherwise holding on to the general pattern.
The text was updated successfully, but these errors were encountered: