Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Why do which and type point to different paths?</p> </blockquote> <p>If your shell has hashed <code>ipython</code>'s path, <code>type</code> will give you the hashed path without searching <code>$PATH</code>, while <code>which</code> will ignore the hashed path and do the search.</p> <p>Assuming your shell is <code>bash</code>, the <code>hash</code> command (with no args) will show you the hashed paths, or you can look at the <code>BASH_CMDS</code> associative array. But you already know that <code>ipython</code> is hashed, because <code>type</code> just told you.</p> <p>Usually you can fix this by just starting a new shell, using the <code>hash -r</code> command (to wipe the cache without restarting anything else), or <code>hash -d ipython</code> (to remove just <code>ipython</code> from the cache—but make sure you don't also have, e.g., <code>python</code> in the cache). With different shells, the two commands may be different (e.g., in *csh and zsh, it's <code>rehash</code> and <code>rehash ipython</code>, respectively), but starting a new shell should always works.</p> <p>For more details, see the <a href="http://www.gnu.org/software/bash/manual/bashref.html#Command-Search-and-Execution" rel="nofollow">Command Search and Execution</a> in the bash reference manual, or the <code>bash(1)</code> manpage on your system, or the numerous easier-to-understand blog posts that will show up if you google something like "bash hash cache" (like <a href="http://bradconte.com/bash-path-hashing" rel="nofollow">this one</a>).</p> <blockquote> <p>Why, if IPython is installed in my virtualenv, does the system IPython get executed</p> </blockquote> <p>If your shell has hashed <code>ipython</code>'s path, <code>ipython</code> will run from the hashed path, without searching <code>$PATH</code>.</p> <p>Again, starting a new shell, etc., should fix this.</p> <blockquote> <p>In any case, why does import novaclient bomb out with what seems to be a pretty bizarre error?</p> </blockquote> <p>Most likely it's getting the <code>PYTHONPATH</code> from your environment, which causes the venv's site-packages and dist-packages to come become the system Python's, and the packages in those locations don't work with the system Python.</p> <p>You can verify this by printing out <code>sys.path</code>. But the fact that it's complaining about files in <code>/Users/sam/.virtualenvs/myvirtualenv/lib/python2.7/site-packages/</code> implies that this path must be on <code>sys.path</code>. And (since you're running from a different directory) not just because the default <code>.</code> is picking it up, but because it's there explicitly. So, all that <code>sys.path</code> could tell you is whether it's an absolute or relative path.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload