Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem #2136

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

dkattan
Copy link
Contributor

@dkattan dkattan commented Feb 13, 2024

PR Summary

Removes artificial Uri schema restriction, provides a mechanism for language clients to specify URIs that direct to PSProviders

PR Context

@dkattan dkattan marked this pull request as ready for review February 14, 2024 19:55
@dkattan dkattan requested a review from a team as a code owner February 14, 2024 19:55
@dkattan
Copy link
Contributor Author

dkattan commented Feb 14, 2024

@andyleejordan Curious your thoughts on this. It ended up being heavier-handed than I wanted with all the async changes, but I'm wondering if that would be desirable if I split it into a separate MR? I know @SeeminglyScience doesn't want me changing the public interfaces, but they likely should've been Task<> from the start, async or not.

@dkattan dkattan changed the title Asyncify WorkspaceService/Perform File IO operations through PowerShell Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem Feb 15, 2024
@dkattan dkattan changed the title Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem Draft: Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem Feb 15, 2024
@dkattan dkattan marked this pull request as draft February 15, 2024 21:36
@dkattan dkattan changed the title Draft: Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem Replaced WorkspaceFileSystemWrapper with Get-Content and Get-ChildItem Feb 15, 2024
@SeeminglyScience
Copy link
Collaborator

I know @SeeminglyScience doesn't want me changing the public interfaces, but they likely should've been Task<> from the start, async or not.

Can you talk through what you're trying to solve? When you make a synchronous method return Task<> all you're really doing is requiring wrapper object be created that will be immediately discarded. It doesn't change the behavior at all if that's the assumption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants