-
Notifications
You must be signed in to change notification settings - Fork 740
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
Fix broken tests in test_registry #707
Conversation
pyproject.toml
Outdated
@@ -1,3 +1,6 @@ | |||
[build-system] | |||
requires = ["setuptools>=61.0"] | |||
build-backend = "setuptools.build_meta" | |||
|
|||
[tool.pytest.ini_options] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if it would be a better practice to avoid this project level event loop config to use @pytest.mark.asyncio(loop_scope="function")
for each test case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think being explicit with scopes with fixtures is a good practice and we should keep doing it for our fixtures.
I think it should be fine to have this config. It is not so we can avoid setting explicit scopes, but just to have the default scope when the scope is not specified as pytest-asyncio
will eventually change it "function" by default - in the end we get the same. This way we only explicitly say it so we don't get the warning telling us our default scope will be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @yanxi0830 -- I don't think we should set a default here. we should silence the warnings explicitly because the scope of a fixture is pretty important to think through. A function scope is good for isolation but cannot be too expensive and sometimes just not intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review. I removed the default configuration in tool.pytest.ini_options and now we have only the test fix.
Summary: Tests were broken after registry.get return type was changed from `List[RoutableObjectWithProvider]` to `Optional[RoutableObjectWithProvider]` in efe791b#diff-5de152bae521b7baef01048a4c0142484f8f1c978a04f3b55f4e4dabc52835beL29 Test Plan: Run tests ``` pytest llama_stack/distribution/store/tests/test_registry.py -v collected 6 items llama_stack/distribution/store/tests/test_registry.py::test_registry_initialization PASSED [ 16%] llama_stack/distribution/store/tests/test_registry.py::test_basic_registration PASSED [ 33%] llama_stack/distribution/store/tests/test_registry.py::test_cached_registry_initialization PASSED [ 50%] llama_stack/distribution/store/tests/test_registry.py::test_cached_registry_updates PASSED [ 66%] llama_stack/distribution/store/tests/test_registry.py::test_duplicate_provider_registration PASSED [ 83%] llama_stack/distribution/store/tests/test_registry.py::test_get_all_objects PASSED [100%] ```
Summary:
Tests were broken after registry.get return type was changed from
List[RoutableObjectWithProvider]
toOptional[RoutableObjectWithProvider]
in efe791b#diff-5de152bae521b7baef01048a4c0142484f8f1c978a04f3b55f4e4dabc52835beL29Test Plan:
Run tests