refactoring

[MatthiasBienvenu]

the current file hierarchy has some issues:

• the current src directory is misleading because it includes cpp code for the arduino inside the LL directory which is not to be imported and is contrary to the src layout principles https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/
• the directories file names do not respect always respect the snake case python standard and are sometimes written in french
• some files and directories are useless (like CameraVision which is 100% chatgpt btw)
• also we should use a linter such as (based)?pyright

[Danura30082]

+1 on linter see #14

[MatthiasBienvenu]

I think we should use uv_build as a build-system for the project

[MatthiasBienvenu]

maybe we should do a monorepo with their own pyproject.toml and scripts dir ?

[Danura30082]

maybe we should do a monorepo with their own pyproject.toml and scripts dir ?

I dont think so. We just need to better organise the repo

[Danura30082]

I think we should use uv_build as a build-system for the project

What do you mean by this? There is nothing to build, its python, an interpreted language

[MatthiasBienvenu]

maybe we should do a monorepo with their own pyproject.toml and scripts dir ?

I dont think so. We just need to better organise the repo

What could be done instead would be a workspace which is apparently idiomatic for tools like uv https://docs.astral.sh/uv/concepts/projects/workspaces/
This would let us have a separate venv and pyproject.toml for each division (mainly HL and Simulation) while still having a global uv.lock for cross compatibility.
I think that would really ease up dependency management.
The way we currently do it is with optional dependency groups of a global venv which is kind of a hack a feels very unintuitive.

to get to such a layout in an idiomatic way I would suggest to have a layout like that :

.
├── pyproject.toml
├── README.md
├── src
│ ├── high_level
│ │ ├── pyproject.toml
│ │ ├── README.md
│ │ ├── scripts
│ │ │ └── some_script.py
│ │ └── src
│ │ ├── backend
│ │ │ ├── init.py
│ │ │ └── something.py
│ │ └── high_level
│ │ └── init.py
│ └── simulation
│ ├── pyproject.toml
│ ├── README.md
│ ├── scripts
│ │ └── some_other_script.py
│ └── src
│ ├── simulation
│ │ └── init.py
│ ├── simulation.py
│ └── webots
│ ├── init.py
│ └── something_else.py
└── uv.lock

I'm still thinking about the names but this is just an idea of the global structure

[MatthiasBienvenu]

What do you mean by this? There is nothing to build, its python, an interpreted language

Python is interpreted, so we don’t need to compile code, but uv_build is still required. It tells uv where our source modules live and how to expose them for imports. It also ensures that uv run works consistently across all the project, and doesn't change execution depending on the location where you run uv run without having to use PYTHONPATH. For our case it is the only feature we care but it also can be used to package our project to publish it on Pypi.