-
Notifications
You must be signed in to change notification settings - Fork 167
Open
Labels
UXRelated to user experienceRelated to user experienceenhancementNew feature or requestNew feature or request
Description
One feature that has come up is to support uv-less running. NeMo RL will always use uv, but for users who want to take a container / code and prefer not dealing with uv at runtime, they should be supported as well.
Code merged into main will always need to be reproducible with uv, but during bringup, it should be more flexible.
Planned support:
Support each venv's python directly
# Directly adding all of these to the PATH
python # equivalent to "uv run"
python-mcore #equivalent to "uv run --extra mcore"
# also allowing pip installs into each venv
python-mcore -m pip install foobar
....
- will need to make sure we seed all environments (
uv venv --seed) - unset UV_PROJECT_ENVIRONMENT (this has caused some issues b/c if you want to do something in another dir like
./3rdparty/vllm, it'll get installed in the default venv instead of a local)- unsetting will now cause
uv runto potentially create a local venv even for nemo-rl (need to address)
- unsetting will now cause
Now that the container can drift from the code and the errors will be more confusing as the version drift increases (due to submodule/package drift), we will need to include a check to make sure the user is aware that their container env has drifted and that they are proceeding anyways. In pseudocode we probably should check:
container_id = local_md5sums(pyproject.toml, uv.lock, *submodule_shas)
if container_id != container_md5sum:
logging.warning("Container does not match code")
if not getenv("NRL_IGNORE_VERSION_MISMATCH"):
raise RuntimeError("Your container dependencies do not match your code, set NRL_IGNORE_VERSION_MISMATCH")Metadata
Metadata
Assignees
Labels
UXRelated to user experienceRelated to user experienceenhancementNew feature or requestNew feature or request