Fix #3854

[jonozzz]

If a test was found in a file that started with a capital letter within a subpackage of a package pytest would collect it twice.

Fix #3796, fix #3854

[jonozzz]

I'm not sure why it doesn't load the config from the generated pytest.ini and instead it picks tox.ini. Should I pass it explicitly as an argument -c pytest.ini ?

[nicoddemus]

I'm not sure why it doesn't load the config from the generated pytest.ini and instead it picks tox.ini. Should I pass it explicitly as an argument -c pytest.ini ?

Sorry what do you mean? You are not talking about the failing CI right, because it failed during linting.

[jonozzz]

I'm talking about the AppVeyor CI which failed test_package_ordering. It's as if the ini file that the tests generates was ignored.

[nicoddemus]

Oh sorry did not realize that, I only looked at Travis.

It is confusing (and I just noticed this now), but makeini creates a tox.ini file:

pytest/src/_pytest/pytester.py

Lines 578 to 580 in f2e35c8

	def makeini(self, source):
	"""Write a tox.ini file with 'source' as contents."""
	return self.makefile(".ini", tox=source)

So it seems it is picking up the correct file:

---------------------------- Captured stdout call -----------------------------
============================= test session starts =============================
platform win32 -- Python 3.7.0, pytest-3.7.3.dev50+ga3060e45, py-1.5.4, pluggy-0.7.1 -- c:\projects\pytest\.tox\py37\scripts\python.exe
cachedir: .pytest_cache
rootdir: C:\Users\appveyor\AppData\Local\Temp\1\pytest-of-appveyor\pytest-0\test_package_ordering0, inifile: tox.ini
plugins: hypothesis-3.69.1
collecting ... collected 4 items

[jonozzz]

Ok, then why is it disregarding the python_files option from the ini file. I'm still confused... It's working fine when I run it locally.

[nicoddemus]

Please try to fix the linting issue so Travis can execute the rest of the jobs. This way we will know if it is a windows only issue or a difference between CI and your setup.

I'll be glad to help out with Windows if I can. 👍

[jonozzz]

$ pre-commit run --all-files
black....................................................................Failed
hookid: black

Uhm, I'm not sure what's black and why it failed 😄

[jonozzz]

testing/python/fixture.py:4001:13: F821 undefined name 'dedent'
How can it not be defined when it's clearly imported and even used by other tests. I'm confused...

[nicoddemus]

I'm not sure what's black and why it failed

black is our code formatter. 😉

Take a look at the contribution guide on how to install pre-commit so all of our checks happen on each commit. 👍

[jonozzz]

Ok, done that, I did a quick tox -e linting, and still nothing.

  linting: commands succeeded
  congratulations :)

[nicoddemus]

Ok, done that, I did a quick tox -e linting, and still nothing.

Strange, that usually does the trick for me... I will check your branch later when I get home. 👍

Meanwhile if @asottile has some time to help it would be great as well.

[asottile]

Implicit conflict with master, I changed the import in #3864

merge / rebase and you should be good!

[coveralls]

Coverage increased (+0.05%) to 92.639% when pulling c336449 on jonozzz:fix-3854 into c829061 on pytest-dev:master.

[nicoddemus]

Great work @jonozzz! Please take a look at my comments and see what you think.

Also please add a CHANGELOG entry for the fix. 👍

[nicoddemus]

Perhaps this should be

assert values.pop() == "pre-sub1"

for completeness?

[nicoddemus]

Perhaps this should be

assert values.pop() == "pre-sub2"

for completeness?

[nicoddemus]

To avoid this weird line break by black I usually put the triple strings into a variable:

contents = dedent("""\
    ...
""")
sub2.join("conftest.py").write(contents)

But really up to you, just in case this bothers you. 😉

[asottile]

black is going to reformat that to:

contents = dedent(
    """\
    ...
"""
    )

:rip:

[nicoddemus]

Oh. 😞

[asottile]

you can do this:

x = """\
    ...
"""
print(dedent(x))

but then. meh.

[jonozzz]

@nicoddemus any idea what's up with the failures in the windows CI?

[nicoddemus]

test_package_ordering is failing because windows is case-insensitive, so Test* is matching test_in_sub2.py. I suggest to use a different prefix, check_* for example.

Don't know why TestScopeOrdering.test_multiple_packages is failing though...

[nicoddemus]

I printed the yielded objects in Package.collect:

<Package 'c:\\pytest\\.tmp\\multiple-packages\\root\\sub1'>
<Package 'c:\\pytest\\.tmp\\multiple-packages\\root\\sub2'>
<Module 'test_1.py'>
<Module 'test_2.py'>

This seems correct to me...

[nicoddemus]

Pushed a fix for test_package_ordering, will take a look at TestScopeOrdering.test_multiple_packages when I have sometime tomorrow. 👍

[nicoddemus]

@jonozzz I noticed you pushed another commit to fix test_package_ordering... did you see my previous commit?

[jonozzz]

Well, the whole point of the test was to have a test filename with capital letters. I'd keep all files that start with 'Test'.

[nicoddemus]

Well, the whole point of the test was to have a test filename with capital letters. I'd keep all files that start with 'Test'.

Oh I did not realize that, thanks!

[jonozzz]

I was able to repro the other issue on a local windows machine. I'm looking into it, but I'm still confused.

[jonozzz]

Finally! I hope I squashed that bug. Turns out this new test uncovered an older issue. Phew!

[nicoddemus]

I tested locally and indeed it works, great job!

Just need to fix linting now hehehe.

[asottile]

@jonozzz btw if you run pre-commit install locally it'll let you know as you commit :D

[jonozzz]

Got too excited and pushed it without checking.
Thanks @asottile I need to play around with these hooks.

[nicoddemus]

@jonozzz btw if you add "Fix #NUMBER" to the PR or to one of the commits, the issue will be closed automatically when merged (I just updated the PR description adding that). You can see more here: https://help.github.com/articles/closing-issues-using-keywords/

[jonozzz]

Thanks. Everyday I learn new things 😁 I hope next PRs won't be as messy as this one.

[nicoddemus]

I hope next PRs won't be as messy as this one.

Not at all, anyway it is all part of the process, and we really appreciate all your efforts on this front! 👍