Repository navigation
34 feature pyelk reformating and integration - #39
LudoBroche wants to merge 12 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Solution 1: Python implementationRewrite the required ELK layout algorithm in Python:
Implications
Solution 2: Use
|
|
@loichuder Please have a look at these two solutions described here. I would love to have your opinion. |
There was a problem hiding this comment.
The actual rust wrapper
| #[pyfunction] | ||
| #[pyo3(signature = (graph_json, options_json = "{}"))] | ||
| fn layout_json(graph_json: &str, options_json: &str) -> PyResult<String> { | ||
| layout_api::layout_json(graph_json, options_json).map_err(PyRuntimeError::new_err) | ||
| } |
There was a problem hiding this comment.
We create here our pyfunction
Note this wrapper holds the Python GIL lock.
If necessary, we can improve that by releasing the GIL since Rust doesn't need it.
In the near future I don't think multi-threading of ewoksdraw will be common,
| #[pymodule] | ||
| fn _elk_rs(module: &Bound<'_, PyModule>) -> PyResult<()> { | ||
| module.add_function(wrap_pyfunction!(layout_json, module)?)?; | ||
| Ok(()) | ||
| } |
There was a problem hiding this comment.
And the python module
| [dependencies.org-eclipse-elk-graph-json] | ||
| git = "https://github.com/openedges/elk-rs.git" | ||
| rev = "2191680292b9565592223c22a28b5ef33c3acbad" | ||
| package = "org-eclipse-elk-graph-json" |
There was a problem hiding this comment.
elk-rs doesn't have an official crates and only lives in github.
So we pin the github
There was a problem hiding this comment.
They have tags at least. Could we use a tag instead of revision?
There was a problem hiding this comment.
We call here our rust/python module and Python function to define the desired elk API.
There was a problem hiding this comment.
And we can use it directly
I'd have liked to have yours before 😄 Personally, when I see the Python code of the layout, that looks like several hundred lines of code that I don't wish to maintain. I'd prefer to use the Rust binding. |
|
Agree, I'll go with the rust binding then. |
|
I tested the rust-elk wrapper to generate the graphs. Here is a comparison:
By tuning the option, we can get back to the old system, but I think I like the new compact way better. @loichuder What your take on it ? |
There was a problem hiding this comment.
Since we bundle elk/elk-rs.
I'm adding the licenses for it
There was a problem hiding this comment.
Explain the licensing,
MIT Ewoksdraw
EPL2 for the elk bindings
This is AI Generated I have no knowledge of licensing convention
| id: str | ||
| startPoint: ElkPoint | ||
| bendPoints: list[ElkPoint] | ||
| bendPoints: NotRequired[list[ElkPoint]] |
There was a problem hiding this comment.
A straight edge has no bend point.
In that case elk-rs ignore the key
There was a problem hiding this comment.
testing the binding.
Fake graph and making sure the routing of elks-rs behave as expected:
|
@loichuder It's a little big for my liking; don't be scared to bother and look at it together |
|
Just merged my stack of PRs. Can you rebase? |
27dd3ea to
4a34c58
Compare
|
loichuder
left a comment
There was a problem hiding this comment.
Could you update CONTRIBUTING with the additional requirements to setup the project in dev mode? I think at minimum, there should be a rust installation but perhaps something else?
| result = _elk_rs.layout_json(json.dumps(graph)) | ||
| except RuntimeError as e: | ||
| raise ElkLayoutError(str(e)) from e | ||
| return cast(ElkGraph, json.loads(result)) |
There was a problem hiding this comment.
Do you think we should use a pydantic model instead of a dict for ElkGraph ? This would allow runtime validation and static typing.
| @@ -0,0 +1 @@ | |||
| def layout_json(graph_json: str, options_json: str = "{}") -> str: ... | |||
| are reproduced without modification and included in the wheel and source | ||
| distributions. The upstream notice describes the wider ELK project. | ||
|
|
||
| When updating the elk-rs revision in `rust/Cargo.toml`, update these source |
There was a problem hiding this comment.
Should be part of CONTRIBUTING IMO
| @pytest.mark.parametrize( | ||
| "graph_json, message", | ||
| [ | ||
| ("{not json", "Failed to parse graph JSON"), | ||
| ("[]", "must be a json object"), | ||
| ("{}", "Every element must have an id"), | ||
| ], | ||
| ) | ||
| def test_invalid_graph_raises(graph_json: str, message: str) -> None: | ||
| with pytest.raises(RuntimeError, match=message): | ||
| _elk_rs.layout_json(graph_json) |
There was a problem hiding this comment.
parametrize seems often useful but I feel that it hampers readability.
I think it would read better if this was three separate tests.
| path: dist | ||
|
|
||
| # No checkout and no Rust toolchain: only the wheel is tested | ||
| - name: Install wheel |
There was a problem hiding this comment.
Are we not testing the test from the sources anymore?

PR summary
Import elk algorithms into ewoksdraw
AI Disclosure