feat: REST settings services - #5298
Conversation
Up to standards ✅🟢 Issues
|
|
@mayankansys, in general you could just re-use our existing tests by just parameterizing them. You can avoid any kind of duplication via the adapters, etc. The tests should be the existing ones just by parameterizing them so as to avoid duplication. A few of the extra tests that you have written like over-writing named objects, etc. can be kept but similarly parameterize them for grpc as well. Thank you. |
| # Helpers for transport-parametrized tests (gRPC vs REST) | ||
| # ============================================================================ | ||
|
|
||
|
|
There was a problem hiding this comment.
The settings API can be tested through either REST or gRPC interchangeably. Therefore, given any such API test, one can pass in any solver session object (or its settings attribute).
If you need all the following complications, please explain. Thanks.
| "option": "auto-range-off", | ||
| "auto_range_off": { | ||
| } | ||
| if isinstance(solver, HttpSolver): |
There was a problem hiding this comment.
use same as existing. Don't update paths as part of this PR.
| # HttpSolver (REST transport) has no .exit()/close mechanism yet - guard | ||
| # so REST-parametrized tests don't fail during fixture teardown. | ||
| if hasattr(solver, "exit"): | ||
| solver.exit() |
There was a problem hiding this comment.
We need to incorporate the exit as part of this PR only, but we can do it as a last change after finalizing this PR with other changes first.
| ), | ||
| ] | ||
| ) | ||
| def new_solver_session(request): |
There was a problem hiding this comment.
Create a new one named "solver_session_grpc_rest", and use that for all the tests that needs to use the parameterized fixture testing both grpc and rest server. Keep the "new_solver_session" as it is.
| from ansys.fluent.core.launcher.error_handler import LaunchFluentError | ||
| from ansys.fluent.core.pyfluent_warnings import PyFluentDeprecationWarning | ||
| from ansys.fluent.core.session import BaseSession | ||
| from ansys.fluent.core.session_http_solver import HttpSolver |
There was a problem hiding this comment.
This file will not require any changes after the comment on conftest is addressed.
There was a problem hiding this comment.
| pytest.skip( | ||
| "enable_beta_features()/get_fluent_version() are not applicable to REST transport" | ||
| ) | ||
|
|
There was a problem hiding this comment.
I prefer to simply define what is to be tested fully from the top without any internal conditional skipping. That provides a clean, well defined view of what is and is not covered.
This simple example gets the basic idea across by defining what is to be run from the top and contains no conditionals. It lets the code decide what happens.
# define a test function that only works with gRPC backend:
def do_test_some_solver_features(solver): # ...
# define the test only for gRPC:
def test_some_solver_features(grpc_solver_session):
do_test_some_solver_features(grpc_solver_session)
# that inflates the test code so we can just do it in one go:
def test_some_solver_features(grpc_solver_session): # ...
# @pytest.mark is also possible above but unnecessary
# define a test function that works with either backend:
def do_test_some_other_solver_features(solver): # ...
# define both tests:
# gRPC:
def test_some_other_solver_features(grpc_solver_session):
do_test_some_other_solver_features(grpc_solver_session)
# http:
def test_some_other_solver_features(http_solver_session):
do_test_some_other_solver_features(http_solver_session)
# again, that inflates the test code so we can make use of parametrised fixture selection:
@pytest_fixture(params=...)
def solver_session(...)
return { ...
# run the test with either backend, gRPC or http:
def test_some_other_solver_features(solver_session): # ...
There was a problem hiding this comment.
Thanks @seanpearsonuk, This is exactly what we should so.
github-actions
Bot
added
documentation
ef0401b to
3b01d7a
Compare
- Drop the duplicated PyFluentDeprecationWarning import in session/solver.py (already covered by the grouped ansys.fluent.core.exceptions import). - Sort the session imports in tests/test_settings_api.py. - Remove function-local re-imports of Viscous and VelocityInlets that shadow the module-level import.
Commit a496ce5 (session_solver.py code moved to session_utilities) deleted the from_http classmethod and its TYPE_CHECKING import of HttpSolver without adding them anywhere else, leaving tests/conftest.py calling a method that no longer existed.
The override added a third 'properties' argument that no caller supplies: flobject calls flproxy.create(path, name) with two arguments only. REST now inherits BaseSettings.create, matching the gRPC contract. FluentRestClient.create still accepts 'properties' for direct client use.
d84a60e to
1bb9102
Compare
…into feat/REST_settings
…into feat/REST_settings
4 participants
Context
PyFluent previously supported communication with Fluent solvers exclusively through gRPC-based transport, which requires additional infrastructure and dependencies. There was a need to demonstrate that PyFluent can run seamlessly over both REST and gRPC, allowing users to choose their preferred transport mechanism.
Change Summary
This PR introduces comprehensive REST/HTTP transport support to PyFluent with the following key additions:
New RestSettings class — A settings service wrapper that implements the AbstractSettings interface by delegating all operations to a FluentRestClient instance. Includes schema normalization to convert REST's native hyphenated Scheme keys (e.g., object-type, user-creatable?) to underscore format matching gRPC conventions.
New HttpSolver class — A standalone, lightweight solver session that communicates exclusively over REST, completely independent of gRPC infrastructure. Settings classes are built at runtime from get_static_info() with no need for pre-generated modules.
Factory method — Convenience classmethod to create an HttpSolver instance from a URL and authentication token, making REST-based sessions accessible through the standard Solver interface.
Comprehensive tests — Unit and integration tests covering REST settings wildcard detection, static-info key normalization, nested schema recursion, and end-to-end REST-based workflows.
Rationale
Impact