DylanLukes
commented
2 weeks ago I think I've figured it out. The issue was that my config.toml had shell = "/bin/zsh" rather than just shell = "zsh".
I installed hatch from a copy of the current master branch and spliced in the PyCharm visual debugger integration so that I can explore where exactly things go wrong.
# src/hatch/__init__.py
import pydevd_pycharm
pydevd_pycharm.settrace('localhost', port=33333, stdoutToServer=True, stderrToServer=True)❯ pipx install -e .
⣯ installing hatch from spec '/Users/dylan/PycharmProjects/hatch'
❯ ~/.local/pipx/venvs/hatch/bin/python -m pip install "pydevd-pycharm~=242.20224.347"Then...
VirtualEnvironment.enter_shell does not find a shell executor, and so defaults to self.safe_activation(), which prepends as one would expect. So, ShellManager.enter_zsh is never actually called.
At this point, os.environ["PATH"] is correct. However, hatch then performs os.execvp(command[0], command) where command = ['/bin/zsh'] which as expected re-runs ~/.zshrc.
But notably, the activate script is not ever run via ShellManager.enter_zsh. This seems odd.
Looking into it further, when enter_shell is called:
def enter_shell(self, name: str, path: str, args: Iterable[str]):
shell_executor = getattr(self.shells, f'enter_{name}', None)
if shell_executor is None:
# Manually activate in lieu of an activation script
with self.safe_activation():
self.platform.exit_with_command([path, *args])
else:
with self.expose_uv(), self.get_env_vars():
shell_executor(path, args, self.virtual_env.executables_directory)... it appears that name is "/bin/zsh", so the first call resolves to getattr(self.shells, f'enter_/bin/zsh', None). Obviously this isn't found. As a result, the activate script is not called.
Fixing the configuration file resolves this issue.
Expected Behavior
When running
hatch shell, I expect the hatch virtualenvbinto be prepended to my path, as occurs when sourcing a virtual environment.Problematic Behavior
When running
hatch shell, the hatch virtualenvbinis prepended to my path... before my~/.zshrcruns again and prepends a bunch of other stuff in front of it."Other stuff" includes
asdf, which means.hatch/<default env>/bin/pythonis shadowed by~/.asdf/shims/python.This results in a ton of breakage unless I manually
source .hatch/<default env>/bin/activate.Reproduction
I haven't noticed this behavior before, so I'm not sure if this is a regression of some sort.
First, I create a new project:
Heading inside, I check my path. The contents all make sense to me, I can tell where they're all coming from. There is no mysterious source of shell configuration I'm unaware of contributing to the contents of my
PATH.Now I try to activate the default environment and compare:
Discussion
Hatch seems to be first copying my additions to
PATHexcluding the one set by a plugin (which isasdf). Then, it appears that my~/.zshrcran as usual. Adding anecho SOURCING ZSHRCto my.zshrcconfirmshatch shellis creating a new login shell and sourcing it.Running
source ~.hatch/wtf/bin/activateplaces/Users/dylan/Projects/wtf/.hatch/wtf/binat the top of thePATHas expected. Notably, this file does not appear to be run automatically at any time byhatch shell.