Web-UI update fails to recreate venv

[phillxnet]

Thanks to @FroggyFlox for doing much of the investigation on this one. During our experimental support for openSUSE Leap 15.5 (which in Minimal-VM form has only Py3.6 and no "python" in-path) we observed the following failure to re-create our dedicated .venv via Poetry:

rleap15-5:/opt/rockstor # cat /opt/rockstor/poetry-install.txt

  FileNotFoundError

  [Errno 2] No such file or directory: 'python': 'python'

  at /usr/lib64/python3.6/subprocess.py:1364 in _execute_child
      1360│                     if errno_num != 0:
      1361│                         err_msg = os.strerror(errno_num)
      1362│                         if errno_num == errno.ENOENT:
      1363│                             err_msg += ': ' + repr(err_filename)
    → 1364│                     raise child_exception_type(errno_num, err_msg, err_filename)
      1365│                 raise child_exception_type(err_msg)
      1366│
      1367│
      1368│         def _handle_exitstatus(self, sts, _WIFSIGNALED=os.WIFSIGNALED,

The same failure was not observed if our programmatically generated AT script that we hand off to AT (system scheduler) for our updates was run via cli invocation by the root users (still resourcing AT). @FroggyFlox also found, among many other things, that this same failure could be reproduced on an openSUSE Leap 15.4 system that also did not have a "python" interpreter in the path, only a python3 one.

After quite the journey/exploration it tuns out that we have negative interference from an environmental variable in play that serves no need within our AT/rpm/zypper managed update procedure. This issues failing is also likely related to our recent wiping and re-creating of our .venv virtual environment during rpm upgrade (see rockstor/rockstor-rpmbuild#31) that was required to negotiate our past and future python version jumps.

The proposed fix is to unset the VIRTUAL_ENV environmental variable via the addition of the following line in our AT intended update script:

unset VIRTUAL_ENV

As this setting end up confusing/failing our subsequent rpm/zypper managed rebuild of our venv according to the installing package version via it's %posttrans scriptlet. We have more tidy-up to do in this area as a whole with the following spin-off issues resulting:

#2651
rockstor/rockstor-rpmbuild#43
#2650

A pull request with this proposal is to follow shortly.

[phillxnet]

Closing as:
Fixed by #2654