AcademySoftwareFoundation / AcademySoftwareFoundation/rez

rez-test improvement suggestion. Add " -- " support

Open
#1,223 0 comments 0 reactions 0 assignees View on GitHub
enhancement rez-test
Dominant language
Python
Stars
1.1k
Forks
374
Avg merge
9d 12h
Merged PRs (30d)
5

Description

Just like how `rez-env foo -- echo 'Hello, World!'` jumps into a Rez environment, executes the command, and exits, I think the same functionality would be useful for rez-test. Here's some use cases for why I think it should exist.

# Details
The current rez-test works like this

`rez-test foo` - Runs all default commands listed within all default tests
`rez-test foo bar bazz` - Runs the default commands of both the "bar" and "bazz" tests

The suggestion in this post will keep this same behavior however add " -- "

`rez-test foo -- echo 'Hello, World!'` - Creates a Rez resolve context satisfying "foo" + all default tests. Then runs `echo 'Hello, World!'` and exits.
`rez-test foo bar bazz -- echo 'Hello, World!'` - Creates a Rez resolve context "foo" + "bar" and "bazz" test requires. Then runs `echo 'Hello, World!'` and exits.

# Reasons Why IMO It Should Exist
## CI / Automation
At work and in personal work, I frequently use `tests` for things other than CI and linting. For example, I have 2 commands, "build_documentation" and "publish_documentation" which have a dependency on each other (publish_documentation cannot work if build_documentation does not run first). And these commands are meant to execute automatically on release. But since they need to also be separate commands while working locally, I actually need 3 tests, "build_and_publish_documentation", which does the work of the 2 tests in the expected order. Either that or the release process needs to explicitly search for and call "build_documentation" and "publish_documentation" in that order.

Compare that to this command:

```sh
rez-test some_package build_documentation publish_documentation -- docbot build && docbot publish
```

Simple, expressive, and most importantly, customizable. See the next point below for details.

## Arbitrary Commands == Less Defined Tests
Because `rez-test` does not allow for arbitrary command input with " -- ", it means that the only way to interface with `rez-test` is through the default commands. What if I have a test called "do_something" but I need the command to be slightly different? At the moment, I need to define another identical test environment but with the altered default command.

Allowing " -- " means not having to write extra tests each time a new command is needed, because you can simply call the command you want needed.

## Faster Development

While adding a test to `tests` for the first time, sometimes you need to try out different commands in rapid succession. At the moment to do that, you need to change the "command" key in the `tests` attribute, `rez-build -ci`, wait, and then run `rez-test package my_test_I_want_to_add`.

With " -- ", you'd only need to build once and then run
`rez-test package my_test_I_want_to_add -- command try 1`
`rez-test package my_test_I_want_to_add -- command try 2`
`rez-test package my_test_I_want_to_add -- command try 3`

until you're happy with "command try 3" and then add that to the package.py.

I realize this point has some overlap with `--interactive`, which is already requested over at https://github.com/nerdvegas/rez/issues/665. However for the one-off "I just need to run this command inside of a rez-test's environment", I think this point still stands.

Anyway, what do you think?

Contributor guide

Open the contributing guide

Research direction

Start by tracing the existing rez-test command and comparing its argument handling with rez-env's `--` behavior; the related interactive request is issue #665. Done means preserving current default-test behavior while allowing commands after `--` to run in the resolved test environment, including the documented examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.