Comment 10 for bug 333873

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.
>