Changing dev-mode is not reflected in existing envs
While doing my experiments and realizing what editable installs mean in this context, I've set dev-mode = false and was surprised that coverage still worked.
Running hatch env prune and re-running breaks coverage report as expected.
#771 has a similar discussion. It seems like hatch's approach is not to reinstall a project after an environment is created?
Doesn’t seem like intended behavior. In non-dev-mode, Hatch should reinstall the project on every hatch [env] run
I do not see it spelled out in the documentation but Hatch errs on the side of not reinstalling the distribution or recreating the environment. For example, even with dev-mode = true, when you remove something from project.dependencies, Hatch does not recreate the environment or otherwise try to remove the now extraneous dependency. Similarly, it does not reinstall the distribution when project.scripts is modified (reported in https://github.com/pypa/hatch/issues/771). One could imagine Hatch recreating an environment when project.dependencies or project.scripts (or other metadata) is modified. Likewise, it seems like dev-mode = false installs the project once and leaves it rather than reinstalling every time (like tox does). Maybe a plugin could provide the alternate behavior of reflecting pyproject.toml more closely at the expense of more environment rebuilds.
I think a rebuild of the whole environment isn‘t as important as reflecting the current state of the project, so a setting to reinstall the current version of a project on each run would be nice. (For editable projects, this should be even faster and only update the metadata)
Eventually, even rebuilding the env will no longer be a question: uv, with a warm cache, resolves deps in <10ms and installs hundreds of megabytes in <300ms.
So I think once Hatch has lockfiles and uses uv, we can just sync deps and install the project on each hatch run by default.
This will be fixed and yes UV will improve things when I add that.