This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: APPDATA location in Microsoft Store version
Type: enhancement Stage: resolved
Components: IO, Windows Versions: Python 3.9
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: paul.moore, stephtr, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2020-04-24 13:25 by stephtr, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg367188 - (view) Author: Stephan Troyer (stephtr) Date: 2020-04-24 13:25
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!
msg367216 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-24 19:51
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.
msg367275 - (view) Author: Stephan Troyer (stephtr) Date: 2020-04-25 12:55
> ... 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 😉
History
Date User Action Args
2022-04-11 14:59:29adminsetgithub: 84557
2020-05-14 21:30:08Chris Billingtonsettitle: APPDATA -> APPDATA location in Microsoft Store version
2020-05-14 21:29:20Chris Billingtonsettitle: APPDATA location in Microsoft Store version -> APPDATA
2020-04-30 02:20:50terry.reedysetresolution: third party
2020-04-25 12:55:22stephtrsetstatus: open -> closed

messages: + msg367275
stage: resolved
2020-04-24 19:51:10steve.dowersetversions: + Python 3.9, - Python 3.8
nosy: + paul.moore, tim.golden, zach.ware

messages: + msg367216

components: + Windows
type: behavior -> enhancement
2020-04-24 13:27:27xtreaksetnosy: + steve.dower
2020-04-24 13:25:54stephtrcreate