New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change python command for the default path #122

Closed
uvchik opened this Issue Mar 22, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@uvchik
Copy link
Member

uvchik commented Mar 22, 2016

So far we use the 'HOME' variable for the default oemof path.

import os
homepath = os.environ['HOME']
oemofpath = os.path.join(homepath, '.oemof')

This does not work on Windows because by default the 'HOME' variable is not set on Windows by default. A typical variable using Windows is 'USERPROFILE'.

Commit 2a7a577 fixed that using an if-clause. But it still does not work for the default logging.ini file (see #121).

Another way is to use os.path.expanduser('~').

For Linux both variables lead to the same result: /home/username
Using Windows we get different results (tested on WinXP):
os.environ['HOME']: C:\Dokumente und Einstellungen\username
os.path.expanduser('~'): C:\Programme\WinPython\settings

I think the first one is nicer, but the second one prevents us from using if-clauses and different default files.

@oemof/oemof-main What do you think?

@uvchik uvchik self-assigned this Mar 22, 2016

@uvchik uvchik added this to the March 2016 release milestone Mar 22, 2016

@gnn

This comment has been minimized.

Copy link
Member

gnn commented Mar 22, 2016

So, I found an old (2.7.5.6) ActivePython version on my Windows 7 machine at work, and I get the following results:

ActivePython 2.7.5.6 (ActiveState Software Inc.) based on
Python 2.7.5 (default, Sep 16 2013, 23:16:52) [MSC v.1500 32 bit (Intel)] on win 32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import os
>>> import os.path as osp

>>> sys.platform
'win32'

# Apparently os.envrion... and os.path.expanduser... give the same results here.
>>> os.environ['USERPROFILE']
'C:\\Users\\username-changed-to-protect-the-innocent'
>>> osp.expanduser("~")
'C:\\Users\\username-changed-to-protect-the-innocent'

# Just checking that the HOME environment variable is indeed not defined, so expanduser
# doesn't pick up spurious stuff not existing on other machines.
>>> os.environ['HOME']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "I:\nstallation-location-changed-to-protect-the-innocent\lib\os.py", line 423, in __getitem__
    return self.data[key.upper()]
KeyError: 'HOME'

So at least here, os.path.expanduser("~") would work as expected. I still have to test behaviour on the most recent Windows version, with other Python distributions (WinPython, Conda and whatnot) and other Python versions. Oh, and checking for os.platform == "win32" might blow up on 64bit Python builds... the joys of different platforms.

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Mar 23, 2016

@caro-rli : What is the result of os.path.expanduser('~') at Chris' Windows installation? What Windows installation does he have (version of Windows and Python, 32bit/64bit)?

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Mar 23, 2016

From issue #121 I got the following information:

I use Windows 10 pro

>> os.path.expanduser('~')
'C:\\Users\\username_replaced'
@gnn

This comment has been minimized.

Copy link
Member

gnn commented Mar 23, 2016

So I checked some Python distributions on Windos 7 and they all seem to behave as expected. Thumbs up means that the correct directory, i.e. C:\Users\..., was returned and thumbs down means an error.

Distribution platform version 'USERPROFILE' expanduser('~') 'HOME'
ActivePython 2 32bit win32 2.7.5 👍 👍 👎
ActivePython 2 64bit win32 2.7.10 👍 👍 👎
ActivePython 3 32bit win32 3.4.3 👍 👍 👎
ActivePython 3 64bit win32 3.4.3 👍 👍 👎
Anaconda 2 32bit win32 2.7.11 👍 👍 👎
Anaconda 2 64bit win32 2.7.11 👍 👍 👎
Anaconda 3 32bit win32 3.5.1 👍 👍 👎
Anaconda 3 64bit win32 3.5.1 👍 👍 👎
CPython 2 32bit win32 2.7.11 👍 👍 👎
CPython 2 64bit win32 2.7.11 👍 👍 👎
CPython 3 32bit win32 3.4.4 👍 👍 👎
CPython 3 64bit win32 3.4.4 👍 👍 👎
WinPython 2 32bit win32 2.7.10 👍 👍 👎
WinPython 2 64bit win32 2.7.10 👍 👍 👎
WinPython 3 32bit win32 3.4.4 👍 👍 👎
WinPython 3 64bit win32 3.4.4 👍 👍 👎

They even all report win32 as the platform, which is weird since I'm on a 64 bit machine but at least that means that the platform check doesn't have to be modified, which is good to know. Also, CPython seems to behave weird with respect to version numbers 20160324-1500: That was an issue with me specifying the wrong path for the corresponding python.exe. Table's up to date and should be fine now.
Gonna check Windows 10 too, just to be sure, but I'm not expecting any surprises.

@ckaldemeyer

This comment has been minimized.

Copy link
Member

ckaldemeyer commented Mar 24, 2016

Based on @gnn's detailed analysis and @uvchik's first post using os.path.expanduser('~'). is the only option, right?

I don't mind the behaviour like

os.path.expanduser('~'): C:\Programme\WinPython\settings

The only drawback would be that different oemof-users at the same windows machine might overwrite their .oemof-files.

But maybe we can circumvent this by using a user-exclusive file name.

@ckaldemeyer

This comment has been minimized.

Copy link
Member

ckaldemeyer commented Mar 24, 2016

Oh, I missed another post from @uvchik :

From issue #121 I got the following information:
I use Windows 10 pro

>> os.path.expanduser('~')
'C:\\Users\\username_replaced'

For me, this would be one argument more for expanduser. If Windows XP is the only OS with the behaviour os.path.expanduser('~'): C:\Programme\WinPython\settings we should be fine.

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Mar 24, 2016

I don't mind the behaviour like
os.path.expanduser('~'): C:\Programme\WinPython\settings

This was an old single user WinXP installation. We do not have to care about this.

Thanks @gnn, I try to fix it for the March release.

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Mar 24, 2016

Fixed it with commit 34b5604, even though we do not have any Mac experience.

@uvchik uvchik closed this Mar 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment