Limit search for VCS ignore files in hatchling

[zanieb]

If a Git repository does not contain a .gitignore file, hatchling build will search for one in the parent directories. This makes building source distributions for a package inconsistent across systems as an arbitrary .gitignore file can be selected. This could be resolved by avoiding traversal across git boundaries, i.e. limit the search to a single repository or by disabling this behavior by default (in which case, it will probably be enabled in a monorepo with a .gitignore).

[ofek]

My thought is to maintain the behavior of finding the first ignore file, but then only break if a .git directory is found at some point along traversing up the root or if there is a PKG-INFO in the same directory (implying a source distribution).

How does that sound?

[zanieb]

An example project can be found at https://github.com/astral-test/uv-public-pypackage/tree/395ba191b190da0451c1e67a9b4a1cb5340398e5

Reproduction is something like this

❯ echo "*" > .gitignore
❯ git clone https://github.com/astral-test/uv-public-pypackage
❯ cd uv-public-pypackage
❯ rm -f .gitignore
❯ pip install -e .
❯ python -c "import uv_public_pypackage"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'uv_public_pypackage'

then only break if a .git directory is found at some point along traversing up the root

Would this break if run from the repository root then? Since it'd have a .git directory? GIt submodules seem like an important edge-case to consider as well.

[geodab]

Hello, I came across this issue while troubleshooting why rules from a global .gitignore configuration were not being recognized.

Honoring the first identified .gitignore for a project is not sufficient for the case where the full rule set that would normally apply to a project context also depends on other configuration used by Git.

Rather than try to maintain hatchling specific semantics for resolving and honoring the Git ignore set, would it be possible for hatchling to defer to Git's own ruleset interpretation? For example, something like find . | git check-ignore --stdin will output all the files that should be ignored from the file tree according to whatever Git ignore rules would normally apply to a project, with Git as the authority.

I think asking Git itself to be the filter would also address the concern for projects that do not include a .gitignore file which should then fall back onto whatever heuristic Git uses in that situation.

[ofek]

@geodab That is a good idea and something I wish to support as an option. I'm going to use the following issue to track: #304

[jameshilliard]

My thought is to maintain the behavior of finding the first ignore file, but then only break if a .git directory is found at some point along traversing up the root or if there is a PKG-INFO in the same directory (implying a source distribution).

Finding a .git directory does not actually mean the python project being built is being tracked by git, one also needs validate that the project root itself is not being ignored like in #1643 as an additional check before accepting the ignore rules. While checking for a PKG-INFO file may work in some cases like sdist builds it would still break for build systems that build a project from say a github tarball(so no PKG-INFO) inside a build directory with the project root fully ignored using .gitignore. For example while buildroot typically usually uses sdist based builds for python packages github tarball based builds are also supported for cases where sdist's releases are not available.