APPDATA location in Microsoft Store version

[stephtr]

BPO	40377
Nosy	@pfmoore, @tjguk, @zware, @zooba, @stephtr

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-04-25.12:55:22.614>
created_at = <Date 2020-04-24.13:25:54.829>
labels = ['type-feature', 'expert-IO', 'OS-windows', '3.9']
title = 'APPDATA location in Microsoft Store version'
updated_at = <Date 2020-05-14.21:30:08.300>
user = 'https://github.com/stephtr'

bugs.python.org fields:

activity = <Date 2020-05-14.21:30:08.300>
actor = 'Chris Billington'
assignee = 'none'
closed = True
closed_date = <Date 2020-04-25.12:55:22.614>
closer = 'stephtr'
components = ['Windows', 'IO']
creation = <Date 2020-04-24.13:25:54.829>
creator = 'stephtr'
dependencies = []
files = []
hgrepos = []
issue_num = 40377
keywords = []
message_count = 3.0
messages = ['367188', '367216', '367275']
nosy_count = 5.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'stephtr']
pr_nums = []
priority = 'normal'
resolution = 'third party'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue40377'
versions = ['Python 3.9']

[stephtr]

In Microsoft Store apps, access to %APPDATA% and %LOCALAPPDATA% gets transparently redirected to an app specific location (such as %LOCALAPPDATA%\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache). This is perfect for saving settings etc. of Python scripts and packages, however that doesn't work, when the unredirected paths are returned by a sandboxed Python script and consumed by a 3rd party tool.
One example for the issue created by that is Jupyter, which saves its kernel settings to %appdata% and returns that path when using the command jupyter kernelspec list. However other applications which rely on that output can't access the resulting paths (since their file access doesn't get redirected).
Would it make sense to add some API for accessing the UWP APIs ApplicationData.Current.LocalFolder and ApplicationData.Current.RoamingFolder, which provide a folder path, which doesn't get redirected?

Besides, I want to thank everyone involved in the Microsoft Store version of Python!

[zooba]

You're welcome! We're all involved - apart from a little bit of startup code, it's exactly the same as the regular install.

Right now, I'd say you have a case that needs the regular installer, in order to avoid the appdata redirection.

As for changing it, it seems that thing have been updated again in last year's 1903 update to make AppData redirection even more transparent (ref: https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes#file-system ). So the intent is really clear that these file locations are not supposed to be shared (e.g. by printing out the directory backing the app-local modifications).

What's the best option here? Probably for Jupyter to move the files elsewhere, or provide a way to output the relevant contents of the file on the console rather than just printing the path. Either of those would work fine on Python 3.8 and earlier as well.

I'm not even sure that those UWP APIs are guaranteed to give a path to the redirected folder - that would break reading of unredirected files, as the docs are clear that User\Name\AppData is redirected, not the other way around. So I don't know that it's an option. I'm also not aware of any way to disable the redirection within the app, like there is for WOW64 redirections.

Having thought some more, I really do think the best option is for Jupyter to be able to print out the required information. That means its stored files can be safely backed up/restored (or transferred, if put in Roaming) and other applications can "python -m jupyter kernelspec <some new command>" to get all of the info they need. Even if we added a new API here, they'd still have to make a change, so making a change that works well for all runtime versions is probably preferable for them as well.

[stephtr]

... provide a way to output the relevant contents of the file on the console rather than just printing the path ...

Thanks, I didn't think of that option, that is probably the best way to deal with it. I'll file a bug to jupyter and vscode-python (which in my case relied on that data).
In principle I like the AppData redirection, since that way package specific data also automatically gets cleaned up when uninstalling the Python app.

Because returning paths which include ApplicationData.Current.LocalFolder (and having 3rd party apps accessing files in there) is also suboptimal, I'm closing this issue.

... apart from a little bit of startup code, it's exactly the same as the regular install.

I know, I only mentioned it, since I don't take it for granted to offer a Microsoft Store package and deal with such specific issues, if there exists already another package for Windows 😉