V2 ./pants test.pytest selects interpreter based off of compatibility constraints

[Eric-Arellano]

Currently the V2 task will always use the current interpreter to run Pytest, even if the targets have different requirements. Instead, we must support choosing the interpreter for the subprocess based on the targets' compatibility (which falls back to global compatibility if missing).

Note that we let Pex do the intepreter resolution for us to simplify the Pants code. All we have to do is pass the interpreter constraints to PEX, along with exposing the --python-setup-interpreter-search-paths, and then Pex will handle the resolution for us.

[jsirois]

Note that Pants does not choose the interpreter itself for the subprocess, as it relies on Pex to do the interpreter resolution. We simply must identify the constraints and then pass those constraints and the interpreter search paths to Pex.

NB: You can run a pex with an interpreter of your choice: /my/python /my/pex [args]. With current pex bugs you must add a PEX_PYTHON prefix like so PEX_PYTHON=/my/python /my/python /my/pex [args] (pex-tool/pex#709 & pex-tool/pex#710). So, iff you know where the right python is, you can control that it gets used. This I think is a ways off though since it ultimately requires some rules to compile or resolve the right python and get it in the CAS so you can mix it into the snapshot for the execution request.

[Eric-Arellano]

The source code is complete, modulo requested changes.

This is still missing test code. Stu and I talked a little over Slack about this—not quite sure what is meaningful to test here, e.g. integration test vs unit test. I have to get going for the day but any ideas on what to test would be much appreciated, as I've never done testing with V2 before.

[stuhood]

Thanks, looks good.

As to testing this, a few tools for the toolbelt:

1. It's possible that we can add an @ensure_v2 decorator that (operates on integration tests similar to @ensure_pantsd), and add it to tests like:

   pants/tests/python/pants_test/backend/python/tasks/test_interpreter_selection_integration.py

   Lines 67 to 71 in 3742edb

   	def test_cli_option_wins_compatibility_conflict(self):
   	# Tests that targets with compatibility conflicts collide.
   	binary_target = '{}:deliberately_conficting_compatibility'.format(self.testproject)
   	pants_run = self._build_pex(binary_target)
   	self.assert_success(pants_run, 'Failed to build {binary}.'.format(binary=binary_target))

2. It's possible to unit test any @(console_)rule using run_rule:

   pants/tests/python/pants_test/rules/test_test.py

   Lines 89 to 91 in 3742edb

   	res = run_rule(fast_test, console, (target1, target2), {
   	(TestResult, Address): make_result,
   	})

   ... particularly if you decompose the rule into multiple rules.
3. It's possible to more-unit-than-integration-test any @(console_)rule by directly making a product_request in a TestBase test:

   pants/tests/python/pants_test/engine/test_isolated_process.py

   Lines 274 to 285 in 3742edb

   	def test_integration_concat_with_snapshots_stdout(self):
   	self.create_file('f1', 'one\n')
   	self.create_file('f2', 'two\n')
   	cat_exe_req = CatExecutionRequest(
   	ShellCat(BinaryLocation('/bin/cat')),
   	PathGlobs(include=['f*']),
   	)
   	concatted = self.scheduler.product_request(Concatted, [cat_exe_req])[0]
   	self.assertEqual(Concatted('one\ntwo\n'), concatted)

   ... to take advantage of this method, you'd generally add some shim @rules around the @rules that you're trying to test, and/or add things that you'd like to directly inject (like PythonSetup) as RootRules that you pass in.
4. It's possible to unit-but-mostly-integration-test a @console_rule via ConsoleRuleTestBase:

   pants/tests/python/pants_test/backend/graph_info/tasks/test_list_targets.py

   Lines 22 to 45 in 3742edb

   	class ListTargetsTest(ConsoleRuleTestBase):
   	goal_cls = list_targets.List
   	@classmethod
   	def alias_groups(cls):
   	return BuildFileAliases(
   	targets={
   	'target': Target,
   	'java_library': JavaLibrary,
   	'python_library': PythonLibrary,
   	},
   	objects={
   	'pants': lambda x: x,
   	'artifact': Artifact,
   	'scala_artifact': ScalaArtifact,
   	'public': Repository(name='public',
   	url='http://maven.example.com',
   	push_db_basedir='/tmp'),
   	}
   	)
   	@classmethod
   	def rules(cls):
   	return super(ListTargetsTest, cls).rules() + list_targets.rules()

[stuhood]

Thanks, this looks good to me.

[Eric-Arellano]

Ready for review now. Thanks both for your help getting it to this point!

[Eric-Arellano]

Bikeshed time! In rules files, should we have helper functions like this appear above or below the main @rule and def rules()?

I have no preference and really don't know what's best.

[stuhood]

Bikeshed time! In rules files, should we have helper functions like this appear above or below the main @rule and def rules()?

IMO, it should appear nearest to the @rule that it is being used by. If there were more rules in this file, they might appear above/below a static function for that reason.

But it doesn't really matter.