Hi we use uv to manage dependencies and environments, Hatch might be redundant - what do you think?

Makes sense.
I have extended the PR to include the removal of all hatch dependencies I found, and the docs up to date.
Building and running here.
What do you think? Safe to remove hatch completely?

@gregpr07

@pabshazon We load the buildDomTree.js as a resource in the pip package inside dom/service.py - do we need it for that inside the pip package?

@MagMueller , imo you do not need hatch nor setuptools as dependencies. Not in runtime, and not in dev.

With python -m build you will use hatchling (the minimal build package of hatch), as is configured so in the pyproject.toml file, and it is enough to package the .js file correctly into the dist package without the rest of hatch installed.

As I am looking at dom/service.py, you are managing that using importlib.resources (the native python lib to manage static resources into packages): is cool and efficient imo, and does not require hatch nor setuptools, because hatchling will correctly bundle the package with the .js file in its place.

✅ I did run a test in my local and is working without hatch nor setuptools deps. Committing it here for you to test - I am still unfamiliar with local env cache for testing.

After building, you can unzip the wheel package and check the .js is inside the package.

I think there might be an issue with the build workflows, in which you need the local dist/file to not exist, I have been using rm -rf dist in my local, not sure if you have local_dev scripts (they can help as documentation and automation at the same time).
In your github actions will not make an impact because vms for devops actions start without the 'dist' folder.

✅ Just tested with a fresh .venv and dist and worked well.
I wonder if you have dev scripts or runbooks to ensure all cache is deleted before new builds. Could be a good "first issue recommendation" for contributors.