bilelmoussaoui / flatpak-vscode Goto Github PK

View Code? Open in Web Editor NEW

88.0 88.0 13.0 704 KB

Integrate Flatpak with VSCode

License: MIT License

TypeScript 100.00%

flatpak flatpak-builder flatpak-vscode visual-studio-code-extension

flatpak-vscode's People

Contributors

Stargazers

Watchers

Forkers

hofer-julian aaron-uriel flxzt seadve vamsikrishna-brahmajosyula burniintree k4rakara proletarius101 caspermeijn rmnscnce fsobolev storminstakk nzrosto

flatpak-vscode's Issues

Support build-options in a module

Unknown option --require-version

I have "--require-version=1.1.2" in my finish-args but when attempting to run via flatpak-vscode I get the following error

>>> flatpak-spawn --host flatpak build --with-appdir --allow=devel --bind-mount=/run/user/1000/doc=/run/user/1000/doc/by-app/re.sonny.Workbench --share=ipc --socket=fallback-x11 --socket=wayland --require-version=1.1.2 --device=dri --share=network --talk-name=org.freedesktop.portal.* --talk-name=org.a11y.Bus --env=COLORTERM=truecolor --env=DESKTOP_SESSION=gnome --env=XDG_SESSION_DESKTOP=gnome --env=XDG_SESSION_TYPE=wayland --env=LANG=en_US.UTF-8 --env=XDG_CURRENT_DESKTOP=GNOME --env=WAYLAND_DISPLAY=wayland-0 --env=AT_SPI_BUS_ADDRESS=unix:path=/run/flatpak/at-spi-bus /home/sonny/Projects/Workbench/.flatpak/repo workbench
error: Unknown option --require-version=1.1.2
>>> Child process exited with code 1

I didn't investigate further yet

Hardcode the path to make sure to use SDK's cargo

See #46 (comment)_

Make the logic for finding manifest more picky

gnome-builder validates if the file name of the manifest is a valid app id.

This is helpful for unnecessary opening of json, yaml, and yml files, which could slow down a lot if you have many of them.

Naming issues

Rename quiescent to just isSpinning or isOperation

Currently, it is confusing and hard to spell, apparently

Rename FlatpakRunner to just Runner and FlatpakTerminal to OutputTerminal
Rename EXT_ID with EXTENSION_ID
Remove a bunch of flatpak prefixes in name (Manager, Map etc.)
Use consistent test naming
Rename deactivateIntegrations to unloadIntegrations or something

Some cleanup:

Move @types/js-yaml to devDependencies

Support JSON with comments (JSONC)

Currently, the parser doesn't handle it. I'm not sure if we should properly handle it or properly mark it as unsupported.

If we should support it, something like https://www.npmjs.com/package/jsonc-parser could be used.

See #77 (comment)

bwrap: Can't find source path /run/user/1000/doc/by-app/${app_id}: No such file or directory

VS Code version: 1.64.0 (host, official vscode yum repo)
Flatpak vscode extension version: 0.0.16

It basically only happens every bootup. A weird workaround is to close vscode and open any other flatpak app in host. Then reopen vscode, now everything works properly. The workaround lasts, until another boot. I think something may not be initialized during the configuration of the extension.

Steps to reproduce:

Boot device
Open vscode
Open build terminal or trigger rust analyzer

Output:
bwrap: Can't find source path /run/user/1000/doc/by-app/${app_id}: No such file or directory

Add way to cancel/stop a build

Currently, i use reload window to cancel a build

I'm not sure if it is fine to just kill the child process

Watch manifest & update state accordingly

In case the user modified the manifest to add a dependency, we should automatically offer to re-build or auto-update the config at least.

Improve and/or simplify building pipeline

Currently, I need to run build command thrice, and a rebuild command to actually run the application on the first initialization.

The stop also doesn't work properly when the current command is changed with other.

Preferably, Manifest should only store and handle data, and shouldn't handle build commands.

See #142 too

Handle --require-version properly

First be removed from the finish-args at https://github.com/bilelmoussaoui/flatpak-vscode/blob/master/src/flatpakManifest.ts#L62-L75 because it is problematic for flatpak-builder like the --metadata one
Set the required version as a FlatpakManifest attribute
Get the flatpak --version and store it when the extension starts
Show an error message if version < minRequiredVersion for any step that the user might want to try

Document the extension features

Currently, from vscode, there's no way to know which features the extension brings or which nice to have features are missing. Would be nice if we can document that somewhere in the README.

Build dir not initialized (when running Build the application)

When running the follwing command:
Flatpak: Build the application the following error is raised

> flatpak build --share=network --nofilesystem=host --filesystem=<project_path> --filesystem=<project_path>/.flatpak/repo --env=PATH=$PATH:/usr/lib/sdk/rust-stable/bin --env=RUSTFLAGS=--remap-path-prefix =../ --env=CARGO_HOME=/run/build/project_name/cargo --env=RUST_BACKTRACE=1<project_path>/.flatpak/repo cargo fetch --manifest-path Cargo.toml --verbose <
error: Build directory =../ not initialized, use flatpak build-init

Disable building when there are some errors in the manifest

Related with #1

There could also be message about the missing runtime on the #71's active manifest status bar item.

Check for missing sdk/runtime/baseapp & offer installing them

Would be a neat addition before asking the user to configure their flatpak

Add tests

We should add tests in order to avoid regressions.

Unit tests:

isFlatpak
parseManifest
findManifests

GUI tests:

compile&run a simple apps with all supported buildsystems

Forward the host env variables when running the app

I've noticed that vorta builds fine with Builder, but fails with flatpak-vscode with the following error:

qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

This is because flatpak-vscode executes:

flatpak build --with-appdir --allow=devel \
--bind-mount=/run/user/1000/doc=/run/user/1000/doc/by-app/com.borgbase.Vorta \
 --socket=fallback-x11 --share=ipc --socket=wayland --device=dri \
 --share=network --filesystem=host --own-name='org.kde.*' \
 --talk-name='org.freedesktop.DBus.*' --talk-name='org.freedesktop.Flatpak.*' \
 --talk-name=org.freedesktop.secrets --talk-name=org.kde.kwalletd5 \
 --socket=ssh-auth --talk-name=org.freedesktop.Notifications \
 --system-talk-name=org.freedesktop.NetworkManager \
 --talk-name='org.freedesktop.portal.*' --talk-name=org.a11y.Bus \
 /var/home/julian/Projekte/Others/vorta/.flatpak/repo vorta

while Builder executes :

flatpak-spawn --host flatpak build --with-appdir --allow=devel \
--bind-mount=/run/user/1000/doc=/run/user/1000/doc/by-app/com.borgbase.Vorta \
--socket=fallback-x11 --share=ipc --socket=wayland --device=dri \
 --share=network --filesystem=host --own-name='org.kde.*' \
 --talk-name='org.freedesktop.DBus.*' --talk-name='org.freedesktop.Flatpak.*' \
 --talk-name=org.freedesktop.secrets --talk-name=org.kde.kwalletd5 \
 --socket=ssh-auth --talk-name=org.freedesktop.Notifications \
--system-talk-name=org.freedesktop.NetworkManager \
 --talk-name='org.freedesktop.portal.*' --talk-name=org.a11y.Bus

starting from here come the differences (retracted a few obviously Builder specific commands and emphasized the differences)

--env=COLORTERM=truecolor --env=DESKTOP_SESSION=gnome \
--env=LANG=de_AT.UTF-8 --env=WAYLAND_DISPLAY=wayland-0 \
--env=XDG_CURRENT_DESKTOP=GNOME \
--env=XDG_SESSION_DESKTOP=gnome \
--env=XDG_SESSION_TYPE=wayland \
--env=AT_SPI_BUS_ADDRESS=unix:path=/run/user/1000/at-spi-bus \
--env=TERM=xterm-256color \
 /var/home/julian/Projekte/Others/vorta/.flatpak/repo vorta

Note: the relevant part in that specific case is --env=XDG_SESSION_TYPE=wayland

Don‘t trigger a „run“ when executing „rebuild“

Most IDEs only rebuild the app when being asked to execute „rebuild“. It is not expected that the app will also be run.

It also doesn‘t fit nicely with debugging, because here the app will be run differently.

build-init terminates with exit code 1

build-init terminates with exit code 1. Logs:

> Executing task: flatpak build-init ~/Projects/dialect/.flatpak/repo com.github.gi_lom.dialect org.gnome.Sdk org.gnome.Platform master <

error: org.gnome.Sdk/*unspecified*/master not installed
The terminal process "/usr/bin/zsh '-c', 'flatpak build-init ~/Projects/dialect/.flatpak/repo com.github.gi_lom.dialect org.gnome.Sdk org.gnome.Platform master'" terminated with exit code: 1.

Here we see the command executed includes org.gnome.Sdk org.gnome.Platform master.
However, the runtime-version specified in the Flatpak's manifest is 3.38 as seen here. So, master is the wrong version.

Looking at the code, the culprit could be:

flatpak-vscode/src/tasks.ts

Line 119 in d164894

[['build-init', buildDir, appId, manifest.sdk, manifest.runtime, branch]],

I think runtime-version might be more appropriate here than branch.

Add an export-bundle command

Would be a nice addition for the next release. The hardest part about this, is figuring out when the command is over to show a notification/open the file manager on the output directory.

Document the integrations with the various other extensions

Disabling the extension leaves the rust-analyzer path setting intact

Disabling the extension should remove that setting too so host rust-analyzer gets used.

Setting to disable rust-analyzer sever path override

Sometimes rust-analyzer stops working when the server path is overridden by flatpak-vscode.

One cause is this issue, where the only solution that I know of is to disable rust-analyzer completely to stop it from consuming resources, or to disable flatpak-vscode and delete that override so that rust-analyzer can run on the host ( where it does not hang for me)

But there is also the issue that sometimes rust-analyzer does not start by itself, the only solution I have found that I need to build or run the flatpak at least once and restart vscode.

I think a setting to disable the server path override would be very useful, so that rust-analyzer could run on the host if wanted.

I already have the implementation ready, but I think somebody who actually knows typescript should take a second look at it.
Tell me if this sounds reasonable and I would open a PR.
Thanks!

Make sure that rust analyzer does not complain when there is an empty repo

Currently rust analyzer complains if we don't have a valid repo.
Let's track this here so we don't forget to improve this situation before our first release.

flatpak-builder errors when trying to build a dependency

I'm trying to use this extension to easily build my project using flatpak, but when I try to build it, it fails with this output:

> flatpak-builder --ccache --force-clean --disable-updates --disable-download --build-only --keep-build-dirs --state-dir=/home/melix/Git/melix99/telegrand/.flatpak/flatpak-builder --stop-at=telegrand /home/melix/Git/melix99/telegrand/.flatpak/repo /home/melix/Git/melix99/telegrand/build-aux/com.github.melix99.telegrand.Devel.json <
Emptying app dir '/home/melix/Git/melix99/telegrand/.flatpak/repo'
Initializing build dir
Committing stage init to cache
Starting build of com.github.melix99.telegrand.Devel

(flatpak-builder:2045): flatpak-builder-WARNING **: 18:04:18.721: Failed to get current git checksum: Failed to change to directory “/home/melix/Git/melix99/telegrand/.flatpak/flatpak-builder/git/https_gitlab.gnome.org_GNOME_libadwaita.git” (No such file or directory)
========================================================================
Building module libadwaita in /home/melix/Git/melix99/telegrand/.flatpak/flatpak-builder/build/libadwaita-1
========================================================================
cp: cannot stat '/home/melix/Git/melix99/telegrand/.flatpak/flatpak-builder/git/https_gitlab.gnome.org_GNOME_libadwaita.git': No such file or directory
Error: module libadwaita: Child process exited with code 1

If needed, the project which I'm trying to build is this (use the rewrite branch as the flatpak support is only there). BTW, it builds just fine with gnome-builder.

Clicking on select manifest doesn't work

I opened Contrast (cloned from upstream) and no manifest was automatically selected, clicking on the status bar item shows

command 'flatpak-vscode.select-manifest' not found

cc @SeaDve

Track build state & disable/enable tasks accordingly

We shouldn't re-run build-init for example if the builddir is already there.

Use json schema to detect manifests

Maybe https://www.npmjs.com/package/jsonschema can be used for that

Ctrl-Alt-B runs the app even if the build failed

Ctrl-Alt-B runs the app even if the build failed.

This occurs at least for Rust projects.

Investigate the integration with other extensions/SDKs

Here is a list of the available SDK extensions on Flathub so far, we should check each one of those if there is any potential extension on the VSCode marketplace that we could integrate with if the sdk is used

Hardcoded bash location breaks extension on NixOS

Initializing a build via VSCode running on NixOS, I receive the following in the terminal:

> flatpak build-init /home/osslate/Projects/open-data/.flatpak/repo net.osslate.gnome.OpenData.Devel org.gnome.Sdk org.gnome.Platform 40 <
spawn /usr/bin/bash ENOENT

Some systems such as NixOS and Guix (I imagine) don't place executables and configs where you'd find them on other systems. Executables are stored in Nix stores (in /nix/store) and bootstrapped to /run/current-system/sw/bin/bash at boot, I think.

A fix for this issue might be to use the env command (/usr/bin/env bash) to get the correct location, which does work.

run-tests property isn't recognized

Open VSX Listing: Signing the Publisher Agreement

Thank you for being part of the Open VSX community by adding your extensions to the Open VSX Registry. Please note that the service was recently transferred to the Eclipse Foundation and urgent action on your part is needed so we can continue to list your extensions. To ensure uninterrupted service, please sign the Eclipse Publisher Agreement on or before January 8, 2021. If not signed by that date, your extensions will be delisted and will no longer appear on the site nor be available via the API. If you sign at a later date, your extensions will then be re-activated. The signing process is explained in the Wiki (steps 1 and 2).

Please also note that all extensions MUST have a license in order to be listed.

More details are in these recent blog posts:
https://blogs.eclipse.org/post/brian-king/open-vsx-registry-under-new-management
https://blogs.eclipse.org/post/brian-king/new-era-open-vsx-registry

Today, there’s growing momentum around open source tools and technologies that support Visual Studio (VS) Code extensions. Leading global organizations are adopting these tools and technologies. This momentum has spurred demand for a marketplace without restrictions and limitations. Thanks for joining us on this journey as we continue to build the Open VSX community. We look forward to continued innovation from you in 2021!

Drop the preview flag

Currently the extension is marked as a preview, we should look at dropping that in the future. Let us keep this issue as tracker for the remaining things to do in order to be in a "good enough" state to no longer need that.

`flatpak-spawn`: command not found

I've been working on a project based on the gtk rust template project and am trying to get debugging set up in the flatpak sandbox in VS Code.

I've been working off of the configuration provided in the following issue: #37

I'm currently running into an issue launching the debugger unfortunately.

The error I'm receiving is shown at the end of the issue after outlining some key details from my development environment.

My environment

I'm running Pop!_OS 21.04

rylan@pop-os:~/Code/bitwarden-for-gnome$ flatpak-spawn
flatpak-spawn: command not found
rylan@pop-os:~/Code/bitwarden-for-gnome$ which flatpak-spawn
rylan@pop-os:~/Code/bitwarden-for-gnome$ which flatpak
/usr/bin/flatpak
rylan@pop-os:~/Code/bitwarden-for-gnome$ flatpak --version
Flatpak 1.11.2
rylan@pop-os:~/Code/bitwarden-for-gnome$ which flatpak-builder
/usr/bin/flatpak-builder
rylan@pop-os:~/Code/bitwarden-for-gnome$ flatpak-builder --version
flatpak-builder 1.0.12

VS Code - Relevant Extensions

Flatpak v0.0.12
Native Debug v0.25.1

VS Code `launch.json`

{
	// Use IntelliSense to learn about possible attributes.
	// Hover to view descriptions of existing attributes.
	// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Debug",
			"type": "gdb",
			"request": "launch",
			"preLaunchTask": "flatpak: build",
			"gdbpath": "./gdb.sh",
			"target": ".flatpak/repo/files/bin/bitwarden-for-gnome",
			"arguments": "",
			"cwd": "${workspaceRoot}",
			"valuesFormatting": "parseText"
		}
	]
}

VS Code `tasks.json`

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "shell",
			"command": "flatpak-spawn --host flatpak build --share=network --nofilesystem=host --filesystem=/home/rylan/Code/bitwarden-for-gnome --filesystem=/home/rylan/Code/bitwarden-for-gnome/.flatpak/repo --env=PATH=$PATH:/usr/lib/sdk/rust-stable/bin --filesystem=/home/rylan/code/bitwarden-for-gnome/_build /home/rylan/code/bitwarden-for-gnome/.flatpak/repo meson install -C _build",
			"label": "flatpak: build",
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"problemMatcher": []
		}
	]
}

Output from launching the debugger:

Executing task: flatpak-spawn --host flatpak build --share=network --nofilesystem=host --filesystem=/home/rylan/Code/bitwarden-for-gnome --filesystem=/home/rylan/Code/bitwarden-for-gnome/.flatpak/repo --env=PATH=$PATH:/usr/lib/sdk/rust-stable/bin --filesystem=/home/rylan/code/bitwarden-for-gnome/_build /home/rylan/code/bitwarden-for-gnome/.flatpak/repo meson install -C _build <

/usr/bin/bash: line 1: flatpak-spawn: command not found
The terminal process "bash '-c', 'flatpak-spawn --host flatpak build --share=network --nofilesystem=host --filesystem=/home/rylan/Code/bitwarden-for-gnome --filesystem=/home/rylan/Code/bitwarden-for-gnome/.flatpak/repo --env=PATH=$PATH:/usr/lib/sdk/rust-stable/bin --filesystem=/home/rylan/code/bitwarden-for-gnome/_build /home/rylan/code/bitwarden-for-gnome/.flatpak/repo meson install -C _build'" failed to launch (exit code: 127).

Thank you so much for any & all help on this - it's very much appreciated!

Fix updating dependencies

If you have already built your application and updated the dependencies or added a new one. Running update dependencies leads you to a state where everything is broken and you must run a cleanup and start again which is not great.

Run the build depending on the build system

in order to avoid re-building everything, we do stop-at the latest module, for building that module, we should run meson/ninja or cmake/whatever inside the builddir directory. This way we can get incremental builds

Allow selection of manifests

Currently the extension just takes the first manifest it can find.
It would be nice if it would go through all of them and let the user select which they want to use.

Add colorisation in output

See https://github.com/microsoft/vscode-cmake-tools for inspiration

Rename current `run` to `run-without-rebuild` and current `rebuild` to just `run`

Consider removing flatpak-vscode.rebuild and move its functionality to flatpak-vscode.run.

The rationale is it would be less clutter and confusion with flatpak-vscode.run. Additionally, it helps avoid accidentally running without rebuilding.

"Flatpak manifest detected" is always appearing every startup

I'm not sure if it is intended or a bug. If it is intended, there could be a don't show again, or automatically init a build every launch

GLIBC_2.34' not found error when opening a flatpak rust project

VS Code version: 1.63.2 (from flatpak)
Flatpak vscode extension version: 0.0.16
Rust analyzer extension version: 0.2.853
Application Runtime: GNOME 42

Steps to reproduce:

Open rust flatpak project with this and rust-analyzer extension

Rust Analyzer Client Output:

INFO [2/4/2022, 8:55:33 PM]: Using server binary at /home/dave/Projects/noteworthy/.flatpak/rust-analyzer.sh
DEBUG [2/4/2022, 8:55:33 PM]: Checking availability of a binary at /home/dave/Projects/noteworthy/.flatpak/rust-analyzer.sh
DEBUG [2/4/2022, 8:55:33 PM]: /home/dave/Projects/noteworthy/.flatpak/rust-analyzer.sh --version: {
  status: 1,
  signal: null,
  output: [
    null,
    '',
    "rust-analyzer: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by rust-analyzer)\n"
  ],
  pid: 522,
  stdout: '',
  stderr: "rust-analyzer: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by rust-analyzer)\n"
}
ERROR [2/4/2022, 8:55:33 PM]: Bootstrap error [Error: Failed to execute /home/dave/Projects/noteworthy/.flatpak/rust-analyzer.sh --version. `config.server.path` or `config.serverPath` has been set explicitly.            Consider removing this config or making a valid server binary available at that path.
	at L0 (/home/dave/.var/app/com.visualstudio.code/data/vscode/extensions/matklad.rust-analyzer-0.2.853/out/main.js:109:3705)
	at runMicrotasks (<anonymous>)
	at processTicksAndRejections (internal/process/task_queues.js:93:5)
	at async F0 (/home/dave/.var/app/com.visualstudio.code/data/vscode/extensions/matklad.rust-analyzer-0.2.853/out/main.js:109:1881)
	at async O0 (/home/dave/.var/app/com.visualstudio.code/data/vscode/extensions/matklad.rust-analyzer-0.2.853/out/main.js:108:3977)
	at async lC (/home/dave/.var/app/com.visualstudio.code/data/vscode/extensions/matklad.rust-analyzer-0.2.853/out/main.js:108:3808)
	at async Promise.all (index 0)]

Runtime/Build terminals are broken in flatpaked vscode

They seem to no longer call flatpak-spawn properly

cc @SeaDve

Output channel is noticeably delayed

It probably waits a few moments before flushing the line. The delay could be problematic when watching logs

Guide: Debug with gdb

Install Native Debug
Allow breakpoints everywhere (maybe native debug doesn't include .rs files? Let's open an issue there)

{
    "debug.allowBreakpointsEverywhere": true
}

Create the file gdb.sh with content similar to this (we could create that automatically)
(Note: "Everything before gdb "$@" should be the same command as when you run the flatpak minus the executable name (which is in this case "shortwave))

#!/bin/sh

flatpak-spawn --host flatpak build --with-appdir --allow=devel --bind-mount=/run/user/1000/doc=/run/user/1000/doc/by-app/de.haeckerfelix.Shortwave.Devel --share=network --share=ipc --socket=fallback-x11 --socket=wayland --device=dri --socket=pulseaudio --filesystem=xdg-music --env=RUST_LOG=shortwave=debug --env=RUST_BACKTRACE=1 --talk-name='org.freedesktop.portal.*' --talk-name=org.a11y.Bus --env=DESKTOP_SESSION=gnome --env=XDG_SESSION_DESKTOP=gnome --env=XDG_SESSION_TYPE=wayland --env=LANG=de_AT.UTF-8 --env=XDG_CURRENT_DESKTOP=GNOME --env=WAYLAND_DISPLAY=wayland-0 --env=AT_SPI_BUS_ADDRESS=unix:path=/run/user/1000/at-spi-bus /var/home/julian/Projekte/gnome/applications/Shortwave/.flatpak/repo gdb "$@"

Make gdb.sh executable

chmod +x gdb.sh

Create a file .vscode/launch.json with similar content
(Replace the executable name with yours. We should also auto generate that)

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "gdb",
            "request": "launch",
            "gdbpath": "./gdb.sh",
            "target": ".flatpak/repo/files/bin/shortwave",
            "arguments": "launch.json",
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText"
        },        
    ]
}

Simplify behaviour

In my opinion, the main problem of this extension is that it uses the same building commands as IDEs, but shows a different behaviour.

I would propose to rename tasks and remove a few of them.

Removal of build-init

"build-init" should just be called when a build task is called and the build dir does not exist yet,

No building chain

The automatic start of tasks makes sense because we have so many of them, but it is also surprising and can become annoying.

Simplify tasks

Replace the current tasks with the following:

build

initializes build directory (if necessary)
downloads and builds dependencies
builds the application

rebuild-app-and-run

rebuilds the application and runs the application (same behaviour as before)

run

runs the application (same behaviour as before)

clean

delete the build directory (.flatpak) inside the current workspace (same behaviour as before)

How debugging fits in

Add setting e.g. "flatpak.pythonDebbuging"
If that is true the task "build" adds "debugpy" as last step
After the app has been built the task "debug-python-app" becomes available
A similar procedure would apply for other debuggers than pdb