Introducing "testing" object

[fabal]

Introducing a testing object available in late bindings, similar to the building object, but indicating a rez-test context.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fabal / name: Fabrice Macagno (110cac2, bdf53a3, 471b065)
• ✅ login: nca45 / name: Nate Cheung (6466a13)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.51%. Comparing base (36e0537) to head (6466a13).
Report is 18 commits behind head on main.

❗ Current head 6466a13 differs from pull request most recent head 471b065

Please upload reports for the commit 471b065 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1740      +/-   ##
==========================================
+ Coverage   58.29%   58.51%   +0.22%     
==========================================
  Files         126      126              
  Lines       17159    17095      -64     
  Branches     3505     3506       +1     
==========================================
+ Hits        10002    10003       +1     
+ Misses       6493     6382     -111     
- Partials      664      710      +46     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JeanChristopheMorinPerso]

Just by looking at this PR, I'm struggling to see if it also applies to early bound functions. The description says that it's only for @late, but we have building in @early.

If the changes inject testing in @early, then the documentation should be adapted as such. If it doesn't then I think we should change the PR so that testing will also be available in @early.

Additionally, I would like to see a test or two.

Thanks!

[fabal]

I think early bound attributes are not relevant to rez-test scenarios because they're flattened upon install, meaning any logic will go away anyway. Unless I'm missing something?

I thought about adding some unit tests but I couldn't find counterparts for building use cases? Unless there aren't any?

[fnaum]

I also think that testing does not make sense in @early, as we early decorated functions are evaluated at build time.
so even if we add the object there it would always be false.

[JeanChristopheMorinPerso]

Oh, yeah, you are right about @early, by bad.

As for the tests, I don't think there is any for building and we also don't have tests for rez-test. So it could be a good occasion to add some rez-tests tests.

[fabal]

Sounds good, we've carved out some time to add a few unit tests.

[JeanChristopheMorinPerso]

Looks great! The tests are failing, but I added instructions on how to make them pass.

Also, you will need to run the ./src/build_utils/license/apply_copyright script and fix flake8 warnings.

[JeanChristopheMorinPerso]

Suggested change

	context = ResolvedContext(["testing_obj"])
	self.inject_python_repo()
	context = ResolvedContext(["testing_obj"])

This will add a usable python package and make it available to the tests (only this test). Without this, the tests won't be portable across platforms because we can't rely on python being available on the system. We need python to run the test suite, but that doesn't mean that calling python should work because it doesn't have to be on PATH, and by experience, it will sometimes not be on PATH.

The magic happens in

rez/src/rez/cli/selftest.py

Lines 89 to 93 in 9094b08

	repo = os.path.join(os.getcwd(), "__tests_pkg_repo")
	os.makedirs(repo, exist_ok=True)
	create_python_package(os.path.join(os.getcwd(), "__tests_pkg_repo"))
	os.environ["__REZ_SELFTEST_PYTHON_REPO"] = repo