Refer to virtual environments instead of 'virtualenv' specifically

Because I just learned they're not the same thing, though desktop-app
seems to work with both fine

README.md

@@ -9,7 +9,7 @@ If your application is a Python module runnable from the command line as `python
 mymodule`, then with minimal configuration `desktop-app` can:
 
 * Create a launcher script (or `.exe` on windows) that runs your application
-    * after activating a `conda` environment or virtualenv, if any
+    * after activating a `conda` env or virtuial environment, if any
     * with a hidden console if on Windows
 * Create a start menu shortcut (Windows) or `.desktop` file (Linux) to launch your
   application from your desktop applications menu

desktop_app/environment.py

@@ -79,8 +79,8 @@ def activate_conda_env(name, prefix):
 
 @lru_cache
 def detect_venv():
-    """Inspect whether sys.executable is within a virtualenv and if it is, return the
-    virtualenv Path of prefix. Otherwise return None"""
+    """Inspect whether sys.executable is within a virtual environment and if it is,
+    return the virtual environment Path of prefix. Otherwise return None"""
     if hasattr(sys, 'real_prefix'):
         # virtualenv < v20 sets sys.real_prefix, which doesn't exist otherwise
         return Path(sys.prefix)
@@ -90,10 +90,11 @@ def detect_venv():
 
 
 def activate_venv(prefix):
-    """Modify environment variables so as to effectively activate the given virtualenv
-    from the perspective of child processes. If the virtualenv appears to already be
-    active, do nothing. Does not actually set environment variables, instead returns a
-    copy that may be passed to subprocess.Popen as the env arg."""
+    """Modify environment variables so as to effectively activate the given virtual
+    environment from the perspective of child processes. If the virtual environment
+    appears to already be active, do nothing. Does not actually set environment
+    variables, instead returns a copy that may be passed to subprocess.Popen as the env
+    arg."""
     prefix = Path(prefix)
     env = os.environ.copy()
     current_env = env.get('VIRTUAL_ENV')

desktop_app/launcher.py

@@ -25,8 +25,8 @@ def entry_point():
     is started with a hidden console window. Otherwise the subprocess is run with
     `sys.executable`.
 
-    If `sys.executable` appears to be within a conda or virtualenv environment, then the
-    environment variables of the child process will be modified such that the
+    If `sys.executable` appears to be within a conda env or virtual environment, then
+    the environment variables of the child process will be modified such that the
     environment is effectively activated for the subprocess. In this way an
     `entry_points` script may be run directly (such as from a start menu shortcut)
     without activating the virtual environment it is contained within, and the child

desktop_app/shell.py

@@ -106,11 +106,11 @@ def _get_appid(self):
 
         <module_name>-<envname>
 
-        where <envname> is the name of the conda or virtualenv environment. The env is
-        omitted if it's a conda env called 'base' or a virtualenv called '.venv' or
-        'venv'. The reason we use a different format to Windows is that this will be
-        used as the executable name of the app's process (sys.argv[0]), and so it's
-        slightly more important for it to be user-friendly as it will appear as the
+        where <envname> is the name of the conda or virtual environment. The env is
+        omitted if it's a conda env called 'base' or a virtual environment called
+        '.venv' or 'venv'. The reason we use a different format to Windows is that this
+        will be used as the executable name of the app's process (sys.argv[0]), and so
+        it's slightly more important for it to be user-friendly as it will appear as the
         default window title in some GUI toolkits.
 
         On macos it's the same as Linux, but this is likely to change when proper macos
@@ -120,7 +120,7 @@ def _get_appid(self):
         # Hash the path to the Python interpreter directory so that we can include in
         # the appid a segment unique to the Python environment. .resolve() on the path
         # is important as it gets the correct case of the path - I've observed that in a
-        # virtualenv sys.executable is all lower case. Using the directory instead of
+        # sys.executable within a venv is all lower case. Using the directory instead of
         # the interpreter itself is important so that the hash is the same regardless of
         # whether python or pythonw is in use.
 
@@ -200,7 +200,7 @@ def install(module_name, path=None, verbose=False):
     the start menu on Windows, ~/.local/share/applications on Linux, and TODO on macOS.
     If path is given, the shortcut will be created in the given directory instead. On
     Linux, in order to ensure the name of the shortcut (which may contain the name of a
-    conda or virtualenv environment) matches the name of the executable it points to, a
+    conda or virtual environment) matches the name of the executable it points to, a
     symbolic link called `<module_name>-<envname>` will be created."""
     config = _ModuleConfig.instance(module_name)
     if path is not None: