Backend API: provide path to profile directory

Bug #333873 reported by blackdaemon on 2009-02-24
2
Affects Status Importance Assigned to Milestone
Enso Project
High
Stuart Langridge

Bug Description

Reported by unfocused, Mar 25, 2008

At the moment, Enso is using the HOME environment variable to get the
user's home/profile directory - unfortunately, this doesn't exist in
Windows. Therefore, it needs to be delegated to the platform-specific backends.

My recommendations are as follows:

* On Linux (and probably OSX?): $HOME/.enso/
* On Windows: $APPDATA\Enso\

I suggest a Enso-specific sub-directory so that Enso doesn't pollute the
user's home directory. Plugins should be able to write to this directory -
saving settings, saving data related to learning, etc.

The backends will therefore need to implement a new provider interface, as
the existing ones don't fit with this functionality.

blackdaemon (blackdaemon) wrote :

Comment 1 by stuart.langridge, Jul 11, 2008

On Linux, the folder should be $HOME/.local/share/enso/ -- app-specific files should
go in .local these days.

blackdaemon (blackdaemon) wrote :

Comment 2 by stuart.langridge, Sep 15, 2008

SCRIPTS_FOLDER_NAME is now defined in the community branch (which defines a folder
rather than a file): however, this should be moved somewhere into /platform/ (at the
moment it's hardcoded to the Linux version, ahem). Allow overriding with an
environment variable, but provide sensible defaults for each platform.

blackdaemon (blackdaemon) wrote :

Can we agree on that? I think this is very imnportant issue.

To summarize:

Linux:
  $HOME/.local/share/enso/

  files:
  $HOME/.local/share/enso/.ensorc
  $HOME/.local/share/enso/.ensocommands
  $HOME/.local/share/enso/commands/

  how to get it:
  os.expanduser("~/enso")

OSX:
  $HOME/enso/

  files:
  $HOME/enso/.ensorc
  $HOME/enso/.ensocommands
  $HOME/enso/commands/

  how to get it:
  os.expanduser("~/enso")

Windows XP/Vista:
  C:\Documents and Settings\<username>\Local Settings\Application Data\Enso\

  files:
  C:\Documents and Settings\<username>\Local Settings\Application Data\.ensorc
  C:\Documents and Settings\<username>\Local Settings\Application Data\.ensocommands
  C:\Documents and Settings\<username>\Local Settings\Application Data\Enso\commands\

  how to get it:
  from win32com.shell import shell, shellcon
  os.path.join(shell.SHGetFolderPath(0, shellcon.CSIDL_LOCAL_APPDATA, 0, 0), "Enso")

I suggest creating get_home_folder() or get_enso_folder() somewhere in enso/platform/xxx.

There is also possibility of having heavier platform specific APIs to get important folders, something like:
get_special_folder(constant.ENSO_FOLDER)
get_special_folder(constant.ENSO_LEARNASFOLDER)
get_special_folder(constant.ENSO_COMMANDSFOLDER)

etc.

Changed in enso:
assignee: nobody → blackdaemon
importance: Undecided → High
status: New → In Progress
Stuart Langridge (sil) wrote :

Note that this is basically done now; at the moment there is a specific interface for scripts_folder, which creates the platform-specific Enso folder and then creates "commands" within it. This should be altered to be able to return the platform-specific Enso folder as well (so other commands/modules can store things in it, like learned commands or a config file).

Why does the Windows version have to be so complicated? Can't we do the
below join? And why not put the .ensorc and .ensocommands in the Enso
folder as well like you have for the other OSes (disregard if it was a
typo)? Why use win32com.shell so much? We should try to stick to standard
Python as much as possible if we can get something useable.

os.path.join(os.getenv("APPDATA"),"Enso").

For XP : C:\Documents and Settings\<username>\Application Data\Enso\
For Vista (haven't tested but should be accurate): C:\Documents and
Settings\<username>\Application Data\Local\Enso\

On Tue, Feb 24, 2009 at 10:28 AM, blackdaemon <email address hidden> wrote:

> Can we agree on that? I think this is very imnportant issue.
>
> To summarize:
>
> Linux:
> $HOME/.local/share/enso/
>
> files:
> $HOME/.local/share/enso/.ensorc
> $HOME/.local/share/enso/.ensocommands
> $HOME/.local/share/enso/commands/
>
> how to get it:
> os.expanduser("~/enso")
>
> OSX:
> $HOME/enso/
>
> files:
> $HOME/enso/.ensorc
> $HOME/enso/.ensocommands
> $HOME/enso/commands/
>
> how to get it:
> os.expanduser("~/enso")
>
> Windows XP/Vista:
> C:\Documents and Settings\<username>\Local Settings\Application Data\Enso\
>
> files:
> C:\Documents and Settings\<username>\Local Settings\Application
> Data\.ensorc
> C:\Documents and Settings\<username>\Local Settings\Application
> Data\.ensocommands
> C:\Documents and Settings\<username>\Local Settings\Application
> Data\Enso\commands\
>
> how to get it:
> from win32com.shell import shell, shellcon
> os.path.join(shell.SHGetFolderPath(0, shellcon.CSIDL_LOCAL_APPDATA, 0, 0),
> "Enso")
>
>
> I suggest creating get_home_folder() or get_enso_folder() somewhere in
> enso/platform/xxx.
>
> There is also possibility of having heavier platform specific APIs to get
> important folders, something like:
> get_special_folder(constant.ENSO_FOLDER)
> get_special_folder(constant.ENSO_LEARNASFOLDER)
> get_special_folder(constant.ENSO_COMMANDSFOLDER)
>
> etc.
>
> ** Changed in: enso
> Importance: Undecided => High
> Assignee: (unassigned) => blackdaemon (blackdaemon)
> Status: New => In Progress
>
> --
> Backend API: provide path to profile directory
> https://bugs.launchpad.net/bugs/333873
> You received this bug notification because you are a member of Community
> Enso Team, which is the registrant for Enso Project.
>
> Status in Enso: In Progress
>
> Bug description:
> Reported by unfocused, Mar 25, 2008
>
> At the moment, Enso is using the HOME environment variable to get the
> user's home/profile directory - unfortunately, this doesn't exist in
> Windows. Therefore, it needs to be delegated to the platform-specific
> backends.
>
> My recommendations are as follows:
>
> * On Linux (and probably OSX?): $HOME/.enso/
> * On Windows: $APPDATA\Enso\
>
> I suggest a Enso-specific sub-directory so that Enso doesn't pollute the
> user's home directory. Plugins should be able to write to this directory -
> saving settings, saving data related to learning, etc.
>
>
> The backends will therefore need to implement a new provider interface, as
> the existing ones don't fit with this functionality.
>

blackdaemon (blackdaemon) wrote :

Tim, that's still the same problem. You can't take this for granted:
os.getenv("APPDATA")

That's why there are specific winapi functions for these directories.
On my system there is no env variable for local App data and tnat's what
should be used on Vista.

As soon as you need some more special folder as My Documents, you have
no other chance than use win32com.shell calls.

What is wrong with using system specific libs? You can't avoid it.

Drarok (webmaster-drarok) wrote :

Not sure if it's a typo, but why not keep the OSX layout the same as Linux? There's no harm in creating a .local, and I'd much rather not have an "enso" folder in my home folder.

Stuart Langridge (sil) wrote :

OS X should save things in OS X specific places, so ~/Library/Enso.

Stuart Langridge (sil) on 2009-02-24
Changed in enso:
assignee: blackdaemon → sil-launchpad
blackdaemon (blackdaemon) wrote :

drarok: yes that was a typo. I agree. Anyway, Stuart is taking over this issue.

Tim Biron (timothybiron) wrote :

That's interesting because on my Vista system at home when I do
os.getenv("APPDATA") I am almost 100% certain it returns the local app data
folder that I referenced in my earlier statemen and when I install commands
for testing the Enso folder and commands get created without issue. Why is
there a difference here between Vista instances?

And my statement was that we should use standard Python as long as it is
useable for the task. If it can't be done with standard Python calls then
using a system specific lib is perfectly fine. For instance, getting the
location of the My Documents folder.

On Tue, Feb 24, 2009 at 11:08 AM, blackdaemon <email address hidden> wrote:

> Tim, that's still the same problem. You can't take this for granted:
> os.getenv("APPDATA")
>
> That's why there are specific winapi functions for these directories.
> On my system there is no env variable for local App data and tnat's what
> should be used on Vista.
>
> As soon as you need some more special folder as My Documents, you have
> no other chance than use win32com.shell calls.
>
> What is wrong with using system specific libs? You can't avoid it.
>
> --
> Backend API: provide path to profile directory
> https://bugs.launchpad.net/bugs/333873
> You received this bug notification because you are a member of Community
> Enso Team, which is the registrant for Enso Project.
>
> Status in Enso: In Progress
>
> Bug description:
> Reported by unfocused, Mar 25, 2008
>
> At the moment, Enso is using the HOME environment variable to get the
> user's home/profile directory - unfortunately, this doesn't exist in
> Windows. Therefore, it needs to be delegated to the platform-specific
> backends.
>
> My recommendations are as follows:
>
> * On Linux (and probably OSX?): $HOME/.enso/
> * On Windows: $APPDATA\Enso\
>
> I suggest a Enso-specific sub-directory so that Enso doesn't pollute the
> user's home directory. Plugins should be able to write to this directory -
> saving settings, saving data related to learning, etc.
>
>
> The backends will therefore need to implement a new provider interface, as
> the existing ones don't fit with this functionality.
>

Changed in enso:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers