The main reason is that it's not always desirable to enter a Hatch shell, as it limits what the user can do. For example, it's not possible to prune a Hatch environment that you are inside. So when using direnv, the default env can never be pruned.
The env variables that are set to manipulate Hatch behaviour are not unset after exiting the shell and navigating to another directory, which can create problems when working on other projects.
The approach of setting Hatch env variables does not seem to be supported by Hatch, it seems risky as it may create subtle problems down the line that can be difficult to track down.
Instead, it's preferable to just leave it to limit the devenv to providing consistent environment containing the required tools and commands, and then leave it to the user to manage their own Hatch shells as needed.
The main reason is that it's not always desirable to enter a Hatch shell, as it limits what the user can do. For example, it's not possible to prune a Hatch environment that you are inside. So when using direnv, the default env can never be pruned.
The env variables that are set to manipulate Hatch behaviour are not unset after exiting the shell and navigating to another directory, which can create problems when working on other projects.
The approach of setting Hatch env variables does not seem to be supported by Hatch, it seems risky as it may create subtle problems down the line that can be difficult to track down.
Instead, it's preferable to just leave it to limit the devenv to providing consistent environment containing the required tools and commands, and then leave it to the user to manage their own Hatch shells as needed.