Allow Tracks to Declare Additional Dependencies

If track code would require additional libraries to be installed, it would be good for them to be able to declare them. Because track code is maintained separately from Rally but not executed independently of it, Rally needs to be made aware of special dependencies the track may have.

Rally is more or less a “harness” for the execution of the track. A decent analogy would be the relationship between pytest and the unit tests it runs. It’s entirely possible to run a simple test invocation without further dependencies, but for more complex tests additional dependencies may be required. However, when you require more dependencies to be installed, both of the following workflows are undesirable:

• a documented pip install step that should be taken manually prior to execution (requires both discovery and the knowledge of your workstation-local python ecosystem to manage, including things like upgrades, cleanup, and conflict resolution)
• working through each ModuleNotFoundError as it comes by manually resolving it via pip

The above are rough enough given available tooling in a local environment but the task becomes more bloat-y in an automation environment, where extra dependencies are managed by extra steps, with packages and their versions defined outside of the project itself. Providing a dependency-resolution mechanism via Rally in the track definition is the way to avoid these complications.

I propose we extend the Track Registry concept to allow for additional dependencies, for example:

track.py

def register(registry):
  registry.register_dependency("numpy", "==1.21.4")

Which would be calling…

def register_dependency(library, version_string):

…and would invoke the runtime-local pip in-code, in the fashion mentioned in the pip docs (as a subprocess).

Potential goblins:

1. I’m not sure whether we should try to perform an uninstall of any additional libraries after the race ends (or on any failure, or whatever)
2. Registry invocations are re-run in every worker process, due to load_track being used as a way to ensure all Actors have the track code classloaded. We would likely only want to run pip on the first call per DriverActor, so some check for the library’s existence (and compliance with the version_string) is appropriate

[DJRickyB]

As we maintain multiple versions of tracks, each possibly needing its own specific package/version combinations, just documenting it is not sufficient. Installing packages to your local environment while developing the code is fine, but as soon as those tracks need to be executed:

• In automated, ephemeral contexts
• Across different stack versions (see Rally docs)

Just installing (and uninstalling, and upgrading, and downgrading) packages manually is unsustainable

[cavokz]

Is that the only option? Documenting the dependencies seems good enough for me.