hatch fmt doesn't ignore environments in the project directory

[pfmoore]

Simplest way to demonstrate this:

1. Create a new directory
2. hatch env create
3. hatch fmt

Result:

.venvs\xxyyzz\Scripts\activate_this.py:1:1: INP001 File `.venvs\xxyyzz\Scripts\activate_this.py` is part of an implicit namespace package. Add an `__init__.py`.
Found 3 errors (2 fixed, 1 remaining).

Apart from the formatter finding an error in code that hatch generated for me, it shouldn't even be checking virtual environments.

My config file (which was left over from earlier experiments with hatch, so it was only by chance that I realised this isn't the default behaviour) has

[dirs.env]
virtual = ".venvs"

to put project virtual environments in the project directory.

[ofek]

This is fixed by having VCS ignore files so I think this is expected. Do you think project creation should instantiate Git?

[pfmoore]

I haven't created a project. Literally all I did was hatch env create. And no, this absolutely should not require putting the directory under git control. There's a .gitignore file in the .venvs directory, which was presumably put there by hatch.

Hmm, it appears that ruff check --select INP001 gives the same message. So is this another case (see #1461) where hatch is enabling unsuitable rules? From what I can see, INP001 is prohibiting implicit namespace packages, which is (sorry to be blunt) idiotic - they are a perfectly reasonable Python construct, and blocking them by default is absolutely not something that should be done except as part of a deliberate policy choice (and I'd argue against it even then).

[pfmoore]

I just did a quick experiment. In a new directory, uv venv; ruff check --select INP001 gave no error. The Scripts directory and activate_this.py are basically the same. So I don't know what hatch is doing differently, but ruff/uv successfully ignore the venv.

(Actually, it appears that ruff might explicitly ignore .venv - renaming .venvs to .venv stopped hatch fmt checking the environment).

[ofek]

When you say "created a new directory" what did you mean? I took that to imply you created a directory and then entered the directory and then ran the other two commands.

While implicit namespace packages are completely valid, indeed that is the modern way to do them, that rule is still a useful default because accidentally shipping something that cannot be imported is bad. You have to explicitly configure them with this option.

[pfmoore]

I took that to imply you created a directory and then entered the directory and then ran the other two commands.

Exactly that. You mentioned "project creation", but I didn't create anything that I would consider to be a "project".

that rule is still a useful default because accidentally shipping something that cannot be imported is bad

That's debatable (obviously, because I strongly disagree with you). If you want hatch to be "opinionated" in the stance it takes on things like this, then so be it, but if that's the case, I think you should be up front about that fact and make it clear that hatch's choices will not be to everyone's liking. And that if someone doesn't agree with hatch's choices, they should look for another tool. Basically like black does. They make no bones about the fact that you're buying into a set of policies if you choose to use black.

You have to explicitly configure them with this option.

Not if INP001 is off by default. Which it is in ruff. But this is a discussion more for #1461.

[ofek]

Okay, for the first part I guess to ask is for Hatch configuration to influence the default exclusion patterns. I think I can do that, sure!

As far as that particular rule, I will comment on the other issue.

[pfmoore]

Okay, for the first part I guess to ask is for Hatch configuration to influence the default exclusion patterns.

Sorry, I'm not sure I follow. I may be misunderstanding, but from what I can see:

1. I've globally configured hatch to store environments in the current directory. Hatch knows this.
2. I'm running hatch fmt, which calls ruff. As hatch knows that there's a hatch-managed environment subdirectory in the current directory, isn't it up to hatch fmt to call ruff with arguments that tell ruff to ignore that environment directory?

The fact that ruff cannot recognise hatch's environment directory by default is inconvenient, but not really easy to fix unless we get a de facto (or official) standard for where to store multiple venvs (.venv is the de facto standard for a single venv). I'd hope that ruff would support than standard, and I could then configure hatch to follow it.