search

sassoftware / vscode-sas-extension

This SAS Extension for Visual Studio Code provides support for the SAS language, including features such as SAS syntax highlighting, code completion, hover help, code folding, outline, SAS code snippets and run SAS code.
https://sassoftware.github.io/vscode-sas-extension/
Apache License 2.0
114 stars 47 forks source link

[Viya 4 connection] Support SAS Compute server file system #417

Open gygabyte017 opened 1 year ago

gygabyte017 commented 1 year ago

Is your feature request related to a problem? Please describe. I need to access some sas file that are within the filesystem instead of the Sas Content

Describe the solution you'd like Similarly to what is provided in SAS Studio, I would like to see a SAS Explorer panel that allows me to navigate the SAS server file system, create/edit/delete/rename files and folders, and Upload Files and Folders from the local file system where VSCode is running.

Describe alternatives you've considered NA

Additional context NA

Environment SAS version Viya 3.5 / Viya 4 2023.05

scnwwu commented 9 months ago

VS Code by itself can connect to a remote location and show remote file system in it's Explorer. Refers to https://code.visualstudio.com/docs/remote/remote-overview Will it meet your need?

gygabyte017 commented 9 months ago

@scnwwu Unfortunately I don't think so, because the file system shown in SAS Studio alongside the SAS Content is very hard to be connected to being on some volume in the kubernetes cluster in Viya 4. I don't think there is a secure and easy way to convince the Sas Cloud cysec to directly expose that internal volume on ssh in the network.

clangsmith commented 7 months ago

Ben Gow (a customer) wanted to make sure that when we add this feature that it also honors the fileNavigationCustomRootPath and serverDisplayName config properties, same as SAS Studio. I agree, this makes sense, so that there is a consistent experience between the extension and SAS Studio. So, please make sure to consider this in the implementation.

I am debating whether it makes sense to have separate config properties with the same names, but specific to the extension, or whether the extension should just re-use the existing SAS Studio config properties. The former would allow admins to set the properties separately for the extension and SAS Studio if they wanted them to be different for some reason. However, that would also force them to set both sets of properties if they wanted them to be consistent in the extension and SAS Studio (unless one overrode the other). For this reason, I think the latter makes more sense for now... re-use the SAS Studio config properties, so the extension and SAS Studio are consistent by default. If we get a request later, we could consider adding extension-specific properties that (if set) would override the SAS Studio config properties.

jatran910 commented 6 months ago

I agree that this would be a good feature for the extension. It can help with determining whether issues are isolated or not to SAS Studio when working with the filesystem or configured NFS mounts by having another application that can also access those locations.

clangsmith commented 4 months ago

This should likely be done in coordination with the same feature request for V9 (#889), since they should have a largely consistent experience.

clangsmith commented 2 months ago

We are working on routing an internal requirement (PMSTUDIO-976) to appropriate folks to consider adding the file navigation root options to the Compute Context, so it is under admin control (like it is in V9 and SAS Studio on Viya 4) and so that anyone (or client) who uses a specific Compute Context will get a consistent file navigation root. Otherwise, the best we can do is probably like EG, which stores the file navigation options in the profile, thus can be changed by any end user.