title: Venv home key in pyvenv.cfg
body: <p>For continous integration purposes, I am using the following builtin py3.6 venv command (not to be confused with virtualenv) (see <a href="https://www.python.org/dev/peps/pep-0405/" rel="noreferrer">pep 405</a>).</p>
  
  <pre><code>python -m venv --system-site-packages --without-pip &lt;ENVNAME&gt;
  </code></pre>
  
  <p>I have found it to work great and I am getting an environment instantly.</p>
  
  <p>BUT, .... venv produces a pyvenv.cfg file that looks like that:</p>
  
  <pre><code>home = absolute/path/to/prefix/of/interpreter/which/ran/venv
  include-system-site-packages = true
  version = &lt;interpreter python version&gt;
  </code></pre>
  
  <p>This file contains very crucial home key which refers to the original base python that this venv was created from. Very important to say that an <strong>invalid</strong> home key <strong>crashes</strong> python process which does not find its libraries in the base interpreter.</p>
  
  <p>Now I want to deploy this "tested green" venv + its base python to the production machine. <strong>I don't want to rebuild</strong> it on the production system but just copying it to there.</p>
  
  <p>Needless to say that the home absolute path created on the CI tool is not valid on the production machine, so I need to edit pyvenv.cfg file home key and everything is working like a charm.</p>
  
  <p>This file manipulation is a step I really would like to avoid, as I would like to produce an artifact that just need to copied, activated and called (the standard way).</p>
  
  <p>I tried to put %xyz%, $xyz and even configParser %(xyz)s on the original file but these do not resolve.
  I also tried to use a relative path there, but the path is relative to the working directory and I don't want to force the production system to call my artifact from a pinned working directory.</p>
  
  <p><strong>Is there a solution, other than the ugly pyvenv.cfg manipulation?</strong></p>