ci: fix fixture dir discovery

[autra]

Description

The current conftest is walking the fs hierarchy up until it finds an async-tiff folder. There is 2 problems with this approach:

• some build system / env don't unpack sources in a folder named async-tiff. For instance the nixpkgs build system unpacks it in a source/ dir
• there wasn't a real stop condition in case we didn't find this folder.

This commit finds a folder names fixtures/ instead and add a bulletproof stop condition (I hope).

Note: I haven't tested on windows, and actually, I think it may be better to just hardcode the path like so: (Path(__file__).parent.parent / "fixtures").resolve(). What do you think?

[autra]

Context: I'm currently adding the package to nixpkgs. These 2 problems make an infinite loop in the nixpkgs build.

[autra]

I don't know how to fix that failing pr title validation job though 😅

[kylebarron]

I don't I love this approach because fixtures might not only exist at the top-level. There could be test/fixtures, or there could be test/submodule/fixtures.

I've never seen a workflow that aliases the repo name when checking out the repo. You can't keep the name as async-tiff?

[autra]

I've never seen a workflow that aliases the repo name when checking out the repo. You can't keep the name as async-tiff?

There's plenty of workflow that don't keep the repo name. git clone itself supports it (you can specify a directory name). Build processes like nixpkgs always clone repo to a source folder when building a package. Maybe more importantly, because it's user-facing, git worktree allows this (which I use heavily). And last example (just from the top of my head): if you download the source tarball from pypi, after decompressing the archive, the directory is named async_tiff-0.7.1. I think we just cannot make any assumption about the root directory name.

I don't I love this approach because fixtures might not only exist at the top-level. There could be test/fixtures, or there could be test/submodule/fixtures.

I'm not sure I fully understand this, but then maybe the best way would be to use an explicit relative path, like (Path(__file__).parent.parent / "fixtures").resolve(). What do you think?

[kylebarron]

I don't I love this approach because fixtures might not only exist at the top-level. There could be test/fixtures, or there could be test/submodule/fixtures.

I'm not sure I fully understand this, but then maybe the best way would be to use an explicit relative path, like (Path(__file__).parent.parent / "fixtures").resolve(). What do you think?

The reason why I don't do this is because in local development (in IPython in vscode), __file__ is always the file from which the current Python interpreter was started. This is very inconsistent, and could essentially be any file path, just depending on where I started executing code. So it means I can't run tests interactively if I hard-code the fixtures path based on a relative path to __file__

[autra]

The reason why I don't do this is because in local development (in IPython in vscode), __file__ is always the file from which the current Python interpreter was started.

What command/script are you using to reproduce this behavior? I've never seen anything like it, and the documentation says that __file__ is always the current file absolute path, and does not depend on the initial command you run... From my experience (but I very seldom use vscode), this is indeed what happens. Or maybe I misunderstood something?

[kylebarron]

What command/script are you using to reproduce this behavior?

As an example, this is how I develop all my code, interactively with an IPython/Jupyter pane on the right side. It doesn't update the __file__ per file (since it has no way effectively to know what file I'm in)

Screen.Recording.2026-04-06.at.4.31.46.PM.mov

[kylebarron]

Perhaps the best solution is just to put a .reporoot file at the root of the directory?

[autra]

Oh I see, interesting. That being said, file is wrong outside of test methods, but should be ok when really executing tests right? If I'm right, maybe it's an acceptable tradeoff?

Perhaps the best solution is just to put a .reporoot file at the root of the directory?

Yes, I can do that, or look for a file that is at the root like pyproject.toml for instance?

[kylebarron]

file is wrong outside of test methods, but should be ok when really executing tests right?

It's correctly set when running tests through the python interpreter; just not from interactive mode.

If I'm right, maybe it's an acceptable tradeoff?

Well, when I'm debugging tests I run the test files interactively as I showed above, so it would be annoying to have to manually override the path to fixtures every time I want to debug a test.

Perhaps the best solution is just to put a .reporoot file at the root of the directory?

Yes, I can do that, or look for a file that is at the root like pyproject.toml for instance?

Yeah that sounds fine

[autra]

@kylebarron I've pushed another version detecting pyproject.toml, what do you think?

[kylebarron]

lgtm, thank you!

[kylebarron]

I merged in main to test #297 and see if the commit labeling works... which it looks like it does!

[kylebarron]

Thanks again! And thanks for working on packaging!

[autra]

Thanks to have taken the time to find a solution for everyone!