Don't fail if creating a venv didn't succeed - CP of #26753

[tvalentyn]

Cherrypick #26753 to the release branch.

This removes a usability regression that affects users of custom containers, particularly those using custom Ubuntu-based images, such as off-the-shelf GPU images for RunInference transform.

Asking to CP to the release branch if still possible. Thanks!

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (release-2.48.0@68aa814). Click here to learn what that means.
The diff coverage is n/a.

@@                Coverage Diff                @@
##             release-2.48.0   #26778   +/-   ##
=================================================
  Coverage                  ?   72.04%           
=================================================
  Files                     ?      745           
  Lines                     ?   101204           
  Branches                  ?        0           
=================================================
  Hits                      ?    72916           
  Misses                    ?    26829           
  Partials                  ?     1459           

Flag	Coverage Δ
python	81.07% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[riteshghorse]

Not sure why java checks were triggered on this!.
Merging!

[robertwb]

It doesn't seem very safe to just fall back to the default environment if the virtual environment creation failed...

[tvalentyn]

@robertwb Do you have a specific failure mode in mind?

I could change the check to fall back on default environment if venv module is not available, instead of on any failure. Would that address your concerns?

[robertwb]

Presumably the reason venv was added was to solve some problem (maybe mixing up of dependencies or something like that). Just falling back to not using it would cause it to (non-determanistically) exhibit the same issues that adding this was trying to solve.

Some alternatives would be to make it explicit whether venv should be used (either opt-in or opt-out) or make venv a requirement for Beam (if the user pre-installs beam) or at the very least give a clear error (e.g. "venv is required but not installed in this custom container").

[tvalentyn]

Ok, I filed #26792 to follow up.