File system is busy for serveral seconds after nox session completes when using the virutalenv backend.

[jamesharris-garmin]

Current Behavior

If you were to run nox -s on a session from a working directory on a mounted file system, and then immediately unmount the file system after nox completes:

nox -s <session>
umount /mnt/mount_point

Umount will fail because the fileystem is held open by some scripts that look something like this:

python3 -m pip download --progress-bar off --disable-pip-version-check --only-binary=:all: --no-deps --python-version 3.8 -d /jenkins/.local/share/virtualenv/wheel/house setuptools<71.0.0

Expected Behavior

All file access for processes related to nox are complete and nox is able to unmount the file system.

Steps To Reproduce

1. With a simple noxfile containing a session that installs 3 requirements located on a removable file system
2. Run the following script:

cd /mnt/path/to/noxfile_dir
nox -s simple_session
cd -
umount /mnt/path

This should result in a failure.

Environment

- OS: Ubuntu 20.04
- Python: 3.8.x (latest in ubuntu 20.04
- Nox: 2024.4.15

Anything else?

The suggested fix for this would be to always add the --no-periodic-update flag to nox's internal invocations of virtualenv.

Making this a default virtualenv backend specific feature would developers to avoid having to add complex logic when dealing with cases where uv|virtualenv is specified as the default backend. (--no-periodic-update is a virtualenv specific feature so adding it unconditionally would break other uv backends.

[cjolowicz]

I'd suggest setting the environment variable corresponding to that option in your CI environment.

https://virtualenv.pypa.io/en/latest/cli_interface.html#env-vars

[jamesharris-garmin]

That seems overly combersome. and it was unclear how to set it in a configuration file. Either way I don't see how this is desirable in nox to just periodically grab new versions of the virtualenv embedded dependencies as part of the default behavior.