There is already a card for this (kind of - clean up fixtures using fixtures). I've also discussed this with Marcin at some point and IMO conftest-only importing is the best practice (also recommended by pytest AFAICR). As for wildcard imports, we can disable flake8 check for this in conftest.py only. However, this could be problematic with autouse fixtures, so it's better to use single imports.
On Wed, Jul 7, 2021 at 2:33 PM Eitan Raviv <era...@redhat.com> wrote: > As for wildcard import PEP8 > <https://www.python.org/dev/peps/pep-0008/#imports> does not favor it and > nor do I for the reasons listed in PEP8 and those that Didi listed. > As for having a single file with all imports that would be imported by > conftest, I vote against it because this is similar in a way to importing > with wildcards - a suite will import unused stuff creating all the same > unfavorable effects. > As for importing directly inside the test code I also vote against it, > because - as Didi noted above - there is no single point of access for > imports, posing a risk for collisions, problem to override, and need to > update in several places. > > So by process of elimination what is left AFAIS is to concentrate all the > imports in conftest. > > Thanks > > On Mon, Jun 21, 2021 at 7:03 PM Yedidyah Bar David <d...@redhat.com> > wrote: > >> Hi all, >> >> We have several different styles of where/how to import fixtures in >> ovirt-system-tests: >> >> - import directly inside the test code >> - import in conftest.py >> - import in fixtures modules >> - For all of above, both 'import *' and importing specific fixtures >> >> I think we should try to agree on a specific style and then follow it. >> >> One drawback of importing directly in test/fixtures code is that it's >> then impossible to override them in conftest.py. >> >> A drawback of importing '*' and/or doing this in conftest.py is that >> you might inadvertently import more than you want, or this might >> happen eventually (after more stuff are added), that this makes it >> harder to find what uses what, and that it risks unintended collisions >> in names - as opposed to intended overrides. >> >> A related issue is having to update many places if you add/change >> something. >> >> If there is some kind of "best practices" document somewhere that >> people are happy with, perhaps we should follow it. Otherwise, we >> should come up with our own. >> >> Personally I think I'd like to have a single file with all the >> imports, of specific fixtures (not '*'), and import this file from >> conftest.py of all the suites. Didn't actually try this and no idea >> what complications it might bring. >> >> Comments/ideas/opinions/decisions are welcome :-) >> >> Best regards, >> -- >> Didi >> _______________________________________________ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/privacy-policy.html >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/VAOD5Q7WU2FC66KF5GS3KXWPLCZ2KYS6/ >> > _______________________________________________ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/5DH3G5B2T5ZNF344EZTVY7JQEBFTNINX/ >
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7IVNPQNNVVJRIZJAXLS7CDGI45OBHMQI/
