Currently, the interpreter only supports absolute paths for the 'home' directory in the pyvenv.cfg file.  While this works when the interpreter is always installed at a fixed location, it impacts the portability of virtual environments and can make it notably more-difficult if multiple virtual environments are shipped with a shared interpreter and are intended to be portable and working in any directory.

Many of these issues can be solved for if 'home' can use a directory relative to the directory of the pyvenv.cfg file.  This is detected by the presence of a starting '.' in the value.

A common use-case for this is that a script-based tool (e.g. black or supervisor) may be shipped with a larger portable application where they are intended to share the same interpreter (to save on deployment size), but may have conflicting dependencies.  Since the application only depends on the executable scripts, those packages could be packaged into  their own virtual environments with their dependencies.