The tool allows users to browse their Azure Resources and then use their IDE to make changes to these resources. To do this the tool launches their IDE (as configured in settings or via defaults) and when they save the changes the configuration is submitted to Azure.
While azbrowse isn’t itself an IDE, one way to think of it as a sort of meta IDE in that it is meant to integrate with the developer’s IDEs. In this manner, one could argue it is a candidate for classic.
On the other hand, azbrowse is a specialized file browser which wants the “ability to run other snaps directly (as opposed to defined interfaces)” and wants “access to arbitrary files on the system because the application isn’t designed with confinement in mind”, which are both unsupported use cases.
@lawrence - how does azbrowse launch IDEs? Directly or via some helper like xdg-open? Is it considering mime-types to figure out what to launch or is it just that the user says 'this is my IDE, launch it whenever I open a file in azbrowse"? If the latter, could azbrowse theoretically be updated to consider mimetypes or use a helper like xdg-open or portals?
Thanks for the reply, awesome - if there is a way to make this work in snap then I’m up for it. This is the first snap I’ve attempted to publish and after reviewing docs and other forum posts I couldn’t see a way to make things behave for the use case.
I’m not sure I agree with the definition of azbrowse as a specialized file browser. It’s presenting a tree view over a complex management API and allowing the user to edit a resource then post it back to the API. It’s more like postman than a file browser (that said I do have a feature which uses fuse to try and present the API as a filesystem - this feature isn’t very successful). Sorry being pedantic. Yeah it’s not too far off a file browser.
In the instance of a user trying to edit an azure resource with AzBrowse the following happens.
- User moves through tree in console interface and selects resource to edit. Azbrowse fetches the API endpoint and saves as .json (or yaml) file in temp location
- It launches the editor configured
- User makes an edit then closes the editor (or window in editor depending on editor). It watches the process and waits for it to exit to signify that the edit has been completed
- It reads the .json file from temp location and issues a PUT request to the API endpoint with body set to the contents of the file
Launch args might be, for example:
I’ve contemplated file watches but it feel unfair to infer a save is something that should be updated immediately, for example if a user has something like
autosave on in their IDE.
Is their a way to achieve this flow via snap? My understanding is that
xdg-open wouldn’t let me wait for the process to be closed (step 3/4).
With regard to “access to arbitrary files on the system because the application isn’t designed with confinement in mind” I’m happy to put the files where ever we can save and then allow user to edit and detect that they’re finished in the editor (signal currently is editor closing and process exiting).
Note, I wasn’t asking for you to change your application so much as trying to understand it to see what changes could be made to support it. You are correct that you cannot wait on the process as an external process will fork/exec it.
The temp location is easily addressable: your snap either uses /tmp (which is snap-specific) or somewhere in one of the snap’s writable directories (eg, XDG_RUNTIME_DIR, SNAP_USER_COMMON, etc). The problem is that the application can launch any command as specified as the user.
The requirements for classic are understood.
@pedronis - IME, this is a new use case for classic. In essence, the user configures an editor/IDE to use to edit files in Azure datasources and the snap is expected to launch the editor/IDE itself. It cannot ship all editors as the user can specify anything. A potential future path forward would be some sort of way for the user to declare to snapd what editor azbrowse should use, and then adjust the security policy/mount namespace/userd accordingly in some TBD manner (strict snaps executing other snaps/things in hostfs is obviously problematic atm).
Considering that the editor is user-controlled, the snap is (typically?) not intended to be run as root and there is a (albeit very hand-wavy) potential long term path forward, perhaps this is a candidate for classic?
This wraps around IDEs, I suppose it could be realized with more effort as a family of IDE plugins?
Anyway, as a wrapper of IDEs, it could be probably be treated as an IDE in some sense, the snap doesn’t seem to exist yet in the store though? would it pass publisher vetting?
I agree. azbrowse is now in the store and the requirements are understood. @advocacy - can you please perform the vetting?
Vetting done. +1 from advocacy.
Granting use of classic. This is now live.