blargh. mind opening a ticket?

no problem

sanity check: has anyone used pants on Mojave yet? a few of our engineers have and are getting this error message for

./pants clean

.

FAILURE: (u"Error resolving binary request BinaryRequest(supportdir=bin/watchman, version=4.9.0-pants1, name=watchman, platform_dependent=True, external_url_generator=None, archiver=None): Pants could not resolve binaries for the current host. Update --binaries-path-by-id to find binaries for the current host platform (u'darwin', u'18').\n--binaries-path-by-id was: {(u'darwin', u'11'): (u'mac', u'10.7'), (u'linux', u'amd64'): (u'linux', u'x86_64'), (u'darwin', u'9'): (u'mac', u'10.5'), (u'darwin', u'14'): (u'mac', u'10.10'), (u'darwin', u'17'): (u'mac', u'10.13'), (u'darwin', u'16'): (u'mac', u'10.12'), (u'darwin', u'10'): (u'mac', u'10.6'), (u'darwin', u'15'): (u'mac', u'10.11'), (u'linux', u'i686'): (u'linux', u'i386'), (u'linux', u'x86_64'): (u'linux', u'x86_64'), (u'darwin', u'13'): (u'mac', u'10.9'), (u'darwin', u'12'): (u'mac', u'10.8'), (u'linux', u'i386'): (u'linux', u'i386')}.", MissingMachineInfo(u"Pants could not resolve binaries for the current host. Update --binaries-path-by-id to find binaries for the current host platform (u'darwin', u'18').\n--binaries-path-by-id was: {(u'darwin', u'11'): (u'mac', u'10.7'), (u'linux', u'amd64'): (u'linux', u'x86_64'), (u'darwin', u'9'): (u'mac', u'10.5'), (u'darwin', u'14'): (u'mac', u'10.10'), (u'darwin', u'17'): (u'mac', u'10.13'), (u'darwin', u'16'): (u'mac', u'10.12'), (u'darwin', u'10'): (u'mac', u'10.6'), (u'darwin', u'15'): (u'mac', u'10.11'), (u'linux', u'i686'): (u'linux', u'i386'), (u'linux', u'x86_64'): (u'linux', u'x86_64'), (u'darwin', u'13'): (u'mac', u'10.9'), (u'darwin', u'12'): (u'mac', u'10.8'), (u'linux', u'i386'): (u'linux', u'i386')}.",))


11:17:52 00:01   [complete]
               FAILURE

@acoustic-book-58772 Yes, I needed to upgrade to

1.11.0rc1

for https://github.com/pantsbuild/pants/pull/6591.

it's also possible to add an override: see the linked ticket there https://github.com/pantsbuild/pants/issues/6548

gotcha. Thanks @future-butcher-94831 @witty-crayon-22786!

what are strategies for using shared pytest fixtures? importing them in the tests that use them stops working when the fixtures you import themselves depend on other fixtures. e.g.:

# my_fixtures.py

@pytest.fixture
def foo():
  yield 'foo'

@pytest.fixture
def foobar(foo):
  yield foo + 'bar'

from my_fixtures import foobar

def test_foobar(foobar):
  assert foobar == 'foobar'

the

foobar

fixture will fail to initialize because

foo

isn’t in pytest’s search path for fixtures

one thought is to stick all fixtures you could ever want to use into conftest.py. seems a little weird but not too bad, but it does also have the issue of needing all tests to declare a dependency on the conftest.py file so it exists in the chroot when pytest gets run

from my_fixtures import foobar, foo

def test_foobar(foobar):
  assert foobar == 'foobar'

would also work I think, but it’s weird to make users of

foobar

realize that it depend on

foo

@fierce-park-88503 I'm a bit fixture ignorant, but if pytest could find the

foobar

fixture and the

foo

fixture is in the same file, how is the one " in pytest’s search path for fixtures" and the other not?

... and why

from my_fixtures import foobar, foo

in the test if the test only actually uses

foobar

?

Oh - sorry - the last was you hacking

I’ll find a source in a sec, but basically pytest doesn’t look in all imported modules, just in the test’s own file (which is why importing the unused dep into the test file helps) and some other pre-configured set places (like conftest.py)

OK - your example must be bogus then?

it feels like pytest just decided to re-invent import resolution to make life difficult, but maybe there’s a good reason for it?

Since you o import the 1 file with the two fixtures in it

yes my first example does not work, “the

foobar

fixture will fail to initialize because

foo

isn’t in pytest’s search path for fixtures”

yield looks funky. Does this meant these fixtures return single item iterators? Or does return work and the yield is truly not what you meant?

Shooting in the dark here a bit

A quick experiment shows what you have doesn't work just using two bare files and pytest directly, so - for the record - this is not a pants issue

I am intrigued now though

oh, the

yield

could be a

return

in this case I think. but it wouldn’t make it an iterator,

pytest.fixture

does some context-managery stuff for you, so you can do like:

@pytest.fixture
def thingy():
  # prepare a_thing
  yield a_thing
  # clean up a_thing

https://docs.pytest.org/en/latest/fixture.html#fixture-finalization-executing-teardown-code

and yes, the example I pasted above by itself doesn’t work on its own, w/o pants’ involvement. one solution would be to set up a conftest.py that declares all necessary fixtures. and this also can be made to work in pants, but will require that all tests that use these kinds of fixtures declare conftest.py as a dependency

which is annoying/weird, because it requires that the user of the lib know something about it’s implementation (that it uses hierarchical pytest fixtures) to know that the user must now also declare a dependency on conftest.py

and you can’t make the library that declares the fixture depend on conftest.py, because conftest.py itself needs to depend on it to refer to the module

actually… there might be a way to refer to plugins using just the string of its module name, and not importing the actual module. in which case we could have

user_of_the fixture

depend on

lib_defining_the_fixture

depending on

conftest.py

it’s still somewhat strange that any such test now must import all fixtures declared in conftest.py, not just the ones it wanted

anyway, without more rambling, my point/the question is that pytest’s model here is somewhat at odds with pants’, and I’m wondering what people have done to deal with this

one solution would be to set up a conftest.py that declares all necessary fixtures. and this also can be made to work in pants, but will require that all tests that use these kinds of fixtures declare conftest.py as a dependency

That makes the most sense to me. If you find it distasteful you could write a very small plugin that exposes a

conftests

target that comes with this dep automatically added and use that instead of

python_tests

in your BUILD file(s). This conversation was very confusing for me because it had little to do with pants and alot to do with pytest. Importing a fixture does not work - pants aside - if that fixture depends on another - even in the same file - unless you either a.) import it too (even though you don't use it) or b.) use conftest.py to register all your fixtures. I think the summary is that Pants can't help you today with the extras bogus imports technique in a.) and it forces you to make the implicit dependency on conftest.py to work its magic explicit for technique b.). I'm not sure how we'd make either better except to to ship a canned version of the

conftests

plugin target described above. If you can think of a better idea it's probably worth an enhancement/idea issue to flesh it out.