Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Should `utils_test.py` be considered public API?
See original GitHub issueWe currently expose a number of functions and fixtures in distributed.utils_test. While I would consider these implementation details of our tests, and not part of any stable user-facing API, other projects, including dask/dask rely on them for their test suites (https://github.com/dask/dask/blob/ac74939697c328bd6456aa9fad7d9520328db6e5/dask/tests/test_distributed.py#L11-L14, #5300, #6775, https://github.com/dask/distributed/pull/6802#pullrequestreview-1052813812). This creates friction between the stability requirements of downstream users and our ability to adjust the contents of utils_test to fit our internal testing needs. For example, we cannot easily move functionality around without breaking things for downstream users (https://github.com/dask/distributed/pull/6802#pullrequestreview-1052813812).
This leads me to several questions:
Should the contents of utils_test.py be considered part of the public API?
If so:
- What guarantees are we willing to make around API stability?
- How do we want to test/enforce those?
- Which parts should be considered public API?
- For example, should we only expose context managers/functions, but not fixtures?
If not:
- How do we make this clear and discourage users from importing them?
- How do we deal with projects that already import them?
Issue Analytics
- State:
- Created a year ago
- Comments:14 (14 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
As an aside it’s really painful for us to add new fixture dependencies to our ‘exported’ fixtures because they need to be re-imported completely in a way that appears to violate flake8. Which is why I’d like this new API to use contextmanagers in place of fixtures
Agreed, @graingert. What I would like is some distinction between a smaller module where changes might break stuff for others and a larger module where things will only break
distributed. This would reduce mental load and I can make a conscious decision about introducing breaking changes (and consciously breaking things is a very valid decision here). Right now, I feel like we follow the rule: “If everything is public, then nothing (really) is.”+1 on getting rid of fixtures in the public API.