Skip to content
This repository

Default home not writable, %HOME% does not help (windows) #970

Closed
kubaraczkowski opened this Issue November 03, 2011 · 10 comments

4 participants

Kuba Raczkowski Min RK Thomas Kluyver Fernando Perez
Kuba Raczkowski

Hello, I have trouble with the new Ipython (I think I did not upgrade since 0.10) on windows. My default home directory is not writable (thanks admins!) so previously I had to setup HOME variable pointing to a better location. This, however, does not work with newer ipythons! Any idea why?

Thomas Kluyver
Collaborator
Fernando Perez
Owner

You can also set the environment variable IPYTHON_DIR and then put your ipython directory wherever you want. That's equivalent to Thomas' last suggestion, but is something you can set up once system-wide and be done with it. Let us know if that helps so we can close this issue.

Kuba Raczkowski

Yes, IPYTHON_DIR does help. Could it be added to the windows installation documentation on the website
(http://ipython.org/ipython-doc/stable/install/install.html#windows) ?

Thanks.
Also, the "normal" windows variables (HOMEDRIVE, HOMEPATH) will probably be more often setup by windows administrators, whereas the HOME stays free for the user. What I mean is that that's the variable that is more safe to be changed in enterprise environment, hence more useful for using with custom python/ipython installations...

Thomas Kluyver
Collaborator

I don't think it's a Windows-specific issue, although it would be bizarre to have a non-writable home directory on a Unix-y system. It should be in the docs somewhere, though.

Fernando Perez
Owner
Thomas Kluyver
Collaborator

Fine by me, but I'm not familiar with how environment variables are typically used on Windows. Let's take it to the mailing list - maybe there was a reason it got changed in the first place.

Min RK
Owner

Yes, this has been brought up in #747 as well - I think HOME should be first priority when setting the homedir.

Can I ask, is there a reason that we don't just use os.path.expanduser('~'), and leave it up to Python? Under what circumstances does Python not get the right answer?

Fernando Perez
Owner
Min RK
Owner

It does almost exactly what we do, but in a different order, and notably excluding HOMESHARE. Unfortunately, based on Googling (many results being Brian trying to figure this out in the first place), it looks like cluster-users need to use HOMESHARE, because UNC paths should always be used there (with the wonderful contradiction that UNC paths must never be used for subprocesses).

I think @ellisonbg put HOMESHARE first, because that's the only way to get some parallel things to work on clusters. The problem is, it's the wrong answer approximately everywhere else.

Cluster users are necessarily more advanced than local users, so maybe they should not be prioritized at the expense of everyone else. If we fall back on os.path.expanduser('~'), then cluster users can trivially override the default with: os.environ['HOME'] = os.environ['HOMESHARE'] (or equivalent in the shell, before starting Python). The difference is, HOME is left to the user, whereas HOMESHARE/HOMEDRIVE/HOMEPATH are set by the system, so it makes sense that the easiest one to change should be the first priority, especially since it is already the first priority in Python itself.

I should also note that on first glance, I think the AvoidUNC shenanigans we have to do should be able to wrap os.system, just like they are used to wrap the subprocess. I do not believe that the two are coupled.

Fernando Perez
Owner

I agree, esp. if it means we can simplify some of our code over there and fall back on more stdlib code for this...

Min RK minrk closed this in 351c8fc November 23, 2011
Stefan van der Walt stefanv referenced this issue from a commit in stefanv/ipython November 13, 2011
Min RK defer to stdlib for path.get_home_dir()
We have elaborate and fragile logic for determining
home dir, and it is ultimately less reliable than the stdlib behavior
used for `os.path.expanduser('~')`.  This commit defers to that in
all cases other than a bundled Python in py2exe/py2app environments.

The one case where the default guess will *not* be correct, based on
inline comments, is on WinHPC, where all paths must be UNC (`\\foo`), and
thus HOMESHARE is the logical first choice.  However, HOMESHARE is
the wrong answer in approximately all other cases where it is defined,
and the fix for WinHPC users is the trivial `HOME=%HOMESHARE%`.

This removes the various tests of our Windows path resolution logic,
which are no longer relevant. Further, $HOME is used by the stdlib
as first priority on *all* platforms, so tests for this behavior are
no longer posix-specific.

closes gh-970
closes gh-747
b5ca646
Brian E. Granger ellisonbg referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Brian E. Granger ellisonbg referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.