Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address issue with python3.9 unit testing and turn on by default #3689

Closed
kwigley opened this issue Aug 3, 2021 · 3 comments · Fixed by #4271
Closed

Address issue with python3.9 unit testing and turn on by default #3689

kwigley opened this issue Aug 3, 2021 · 3 comments · Fixed by #4271
Labels
bug Something isn't working tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality

Comments

@kwigley
Copy link
Contributor

kwigley commented Aug 3, 2021

Describe the bug

Unit test run as expected for all python versions except 3.9. We should understand why these tests fail, implement fix, and turn on 3.9 tests.

Steps To Reproduce

run unit test with python3.9

Screenshots and log output

test/unit/utils.py:356: in load_internal_manifest_macros
    return ManifestLoader.load_macros(config, macro_hook)
core/dbt/parser/manifest.py:635: in load_macros
    macro_manifest = loader.create_macro_manifest()
core/dbt/parser/manifest.py:606: in create_macro_manifest
    for path in macro_parser.get_paths():
-----
    def get_paths(self) -> List[FilePath]:
>       return list(FilesystemSearcher(
            project=self.project,
            relative_dirs=self.project.macro_paths,
            extension='.sql',
        ))
E       TypeError: object.__new__() takes exactly one argument (the type to instantiate)

core/dbt/parser/macros.py:21: TypeError

Additional context

I believe this is related to how we mock FilesystemSearcher in other tests? I found that debugging this issue is quite hard. I'll continue to put comments on this issue if I find more info.

@kwigley kwigley added the bug Something isn't working label Aug 3, 2021
@gshank
Copy link
Contributor

gshank commented Nov 10, 2021

I had this same error but it went away after bringing up the docker database and running integration tests. My guess is that it has something to do with creating the adapter singleton, though you wouldn't think so from the test output. But an internet search shows at least a few people running into the same error trying to instantiate a singleton. The FilesystemSearcher class clearly has 3 arguments so that's not a strong candidate for this error.

@gshank
Copy link
Contributor

gshank commented Nov 10, 2021

Or it could be something to do with inheriting from Iterable

@gshank
Copy link
Contributor

gshank commented Nov 11, 2021

It was a mock in test_graph.py

@jtcohen6 jtcohen6 added the tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality label Nov 12, 2021
iknox-fa pushed a commit that referenced this issue Feb 8, 2022
iknox-fa pushed a commit that referenced this issue Feb 8, 2022
automatic commit by git-black, original commits:
  3d28b67
iknox-fa pushed a commit that referenced this issue Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants