-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[path_provider] Add Windows support #2818
[path_provider] Add Windows support #2818
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the review delay. I'm still trying to get Windows CI set up.
/// On Windows, this the path specified by the TMP environment variable, or | ||
/// the TEMP environment variable, or the USERPROFILE environment variable, | ||
/// or the Windows directory, in order of preference. Windows does not | ||
/// guarantee that the path exists or is writeable to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should handle existence here; path_provider
users should be shielded from the platform-specific details, and they are unlikey to come read these docs. Returning a temp path that doesn't exist seems like an unnecessary foot-gun for developers.
packages/path_provider/path_provider_windows/lib/path_provider_windows.dart
Outdated
Show resolved
Hide resolved
packages/path_provider/path_provider_windows/lib/path_provider_windows.dart
Show resolved
Hide resolved
packages/path_provider/path_provider_windows/lib/path_provider_windows.dart
Outdated
Show resolved
Hide resolved
packages/path_provider/path_provider_windows/lib/path_provider_windows.dart
Outdated
Show resolved
Hide resolved
Could you please add support for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple more notes based on having recently been doing Windows plugin work.
It looks like we could have CI online soon (maybe next week?), at which point this will be unblocked. Will you have time to iterate on this PR soon? If not, should we do a handoff? I'd like to get it in ASAP after the CI is online so that we have something exercising the CI to prevent it from breaking without us noticing.
packages/path_provider/path_provider_windows/example/test_driver/path_provider_e2e.dart
Outdated
Show resolved
Hide resolved
/// files. | ||
@override | ||
Future<String> getApplicationSupportPath() => | ||
getPath(WindowsKnownFolder.ProgramData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a mismatch here between what the Windows API gives and what a path_provider user is likely to expect; on mobile these folders are in the app sandbox, so it's reasonable to just create files in the directory returned by getApplicationSupportPath
; in a Win32 app (unless running in a compatibility hypervisor, IIRC) it's the top level folder that all applications share.
For the FDE plugin what I did is append a directory using the executable name (from GetModuleFileName
). I think we need do that (or something like it if there's a better value we have access to) there.
(We may want to add an API to path_provider_windows that allows people to manually set it to a value of their choosing, overriding the default of exe name.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it make sense to place all app data in the userprofile/AppData/local/AppName
as default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I missed that difference from FDE. I was using RoamingAppData; that (or LocalAppData) seems like the right location for application support data. ProgramData sounds like it's not user-specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timsneath I've updated this to match FDE (using RoamingAppData
, and appending the exe name), with a placeholder for the exe name until . Let me know if you have any concerns about using that path.win32
is updated to GetModuleFileName
or GetCurrentProcess
packages/path_provider/path_provider_windows/test/path_provider_windows_test.dart
Outdated
Show resolved
Hide resolved
Thanks for the prod (and for the pull request review comments). It's time I picked this bit up again (got distracted with Windows Runtime API interop improvements). I'll take a look over this Labor Day weekend and see if I can patch this into good shape. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Marking as "reviewed" so it doesn't continue to indicate that the PR is waiting for changes I requested.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all of it looks good except I'm not sure about the need for a Windows-specific sample
@@ -0,0 +1,8 @@ | |||
# path_provider_windows_example |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need a separate sample for Windows? won't the normal path_provider sample do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an open question in the longer term about how to best structure the tests and examples for federated plugins. The plugin repo tooling expects them though, and it does have value in the general case:
- It's a self-contained way to build and test the plugin, which is convenient for plugin development.
- It can test platform-specific APIs (which we don't currently have, but could in the future).
So long term, TBD, short term, this is the standard practice we've been following.
Per #2988 (comment) the application support path approach here isn't correct. I'll need to update the template to add VERSIONINFO, and read that here. |
@timsneath It looks like we'll need |
Have a PR ready that will add these APIs, but I need to add some tests before I merge and publish. I'll do that by EOD. halildurmus/win32#103 |
OK, version APIs are all in win32 v1.7.1 (https://timsneath.github.io/win32/topics/version-topic.html) |
Follows the full convention of company-name\app-name\ as the subdirectory, using the VERSIONINFO resource if there.
@csells Please re-review for the new AppData subdirectory logic. |
I'm going to have to revert this; it appear that it makes the flutter/plugins repo tooling think the tests have failed:
This wasn't happening with the |
This reverts commit 1685a28.
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
Implements path_provider for Windows, adding path_provider_windows and endorsing it in path_provider.
Description
Implements path provider for Windows
Related Issues
Fixes flutter/flutter#41715.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]
). This will ensure a smooth and quick review process.///
).flutter analyze
) does not report any problems on my PR.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?