Load environment variables on requirements-txt

[inoa-jboliveira]

Summary

Expand environment variables that exist into their values accepting only the format ${VARIABLE_NAME_123} where the name must follow the POSIX standard of ASCII upper case letters, numbers and underscore. If the variable does not exist, it will not replace it.

Implements https://github.com/astral-sh/uv/issues/1473

Test Plan

Adds environment variables and checks the expected file is generated

[charliermarsh]

Thanks -- will try to look at this tonight!

[charliermarsh]

So, there's a subtle problem with this. We take a lot of care to ensure that environment variables are preserved with generating the uv pip compile output. E.g., if you have:

black @ file://${PROJECT_ROOT}/black

Then in the generated requirements.txt, we'll have something like:

# This file was autogenerated by uv via the following command:
#    uv pip compile -
black @ file://${PROJECT_ROOT}/black
click==8.1.7
    # via black
mypy-extensions==1.0.0
    # via black
packaging==23.2
    # via black
pathspec==0.12.1
    # via black
platformdirs==4.2.0
    # via black

This is important because it means that the generated requirements don't contain machine-specific paths (or credentials, etc.). If we add the solution presented here, we'll lose that property.

I think instead we need to selectively perform this environment variable replacement in a dedicated set of reported locations. It won't be the same as pip, but I still prefer it. For example, prior to parsing the version specifier on the right-hand side, we may want to first expand environment variables. (It's okay if we don't preserve the environment variable literals in that case -- I mostly care about preserving them in URLs.)

[inoa-jboliveira]

This is important because it means that the generated requirements don't contain machine-specific paths (or credentials, etc.). If we add the solution presented here, we'll lose that property.

Hi, I think .in files and .txt files have different requirements and should be parsed differently. For example if the version of a library is in an env variable in an .in file, you would like it to be converted to a value on a .txt file since the process is to make .txt files as final.

But in the case where .txt files are used directly, they need to be parsed with all the features, right?