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

introduce abstractions to make Flatpak integration easier #555

Merged
merged 14 commits into from
Jul 14, 2021

Conversation

shiftkey
Copy link
Owner

@shiftkey shiftkey commented Jul 13, 2021

Related to #554 but enables us to better combine regular usage as well as integration with the Flatpak host

I've moved the pathExists and spawn usage into a standalone module, so we can keep this platform-specific code isolated from the rest of this app. Not sure how feasible this is, but I hope it makes things easier to reason about if they're funnelling through the same functions (which we can adapt based on the requirements).

cc @AdvaithM for thoughts

I'll add some notes in the PR to help guide the discussion about these changes

TODO

  • get feedback about changes
  • add new vscodium path
  • ensure CI passes
  • test regular usage of app in development mode to ensure no regressions

@@ -1,5 +1,11 @@
export interface IFoundEditor<T> {
readonly editor: T
readonly path: string
/**
* Indicate to Desktop to launch the editor with the `shell: true` option included.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎨 I plan to upstream this change as this context was helpful and perhaps overlooked at the time

} from 'child_process'

export function isFlatpakBuild() {
return __LINUX__ && process.env.FLATPAK_HOST === '1'
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started with a helper method to detect whether we're in a flatpak build. This is now all internal, so I can drop the export above if we're happy with the other changes.

*/
export async function pathExists(path: string): Promise<boolean> {
if (isFlatpakBuild()) {
path = convertToFlatpakPath(path)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 as I understand it, we want to convert program paths before checking if we're running in a flatpak context as they exist in a special location, but we don't need to do this when we want to launch the program - flatpak-spawn will do that itself as long as we call it with --host.

Let me know if this logic is incorrect, or if I've misunderstood.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup this is correct. the path outside the container should be real but detection for binaries in /usr should be pointed to /var/run/host

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about for other special directories we're using for editors:

  • /opt
  • /snap
  • /var/lib/flatpak (launching another flatpak program)

Should those also go through this conversion process before we try and open them with flatpak-spawn?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think /var/lib/flatpak might be blocked by flatpak not sure(I'll check and update this), /snap is one that won't work since this dir won't be mounted

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah /var/lib/flatpak is blocked

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻 I'm assuming that the try-catch below will ensure these errors will be handled and swallowed by the app, so I'm going to try and avoid getting too complex with the logic in here for now for paths that we know are inaccessible in the flatpak context.

options?: SpawnOptionsWithoutStdio
): ChildProcess {
if (isFlatpakBuild()) {
return spawn('flatpak-spawn', ['--host', path, ...args], options)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I think this is the convention for mapping the original command (and parameters) to work with flatpak-spawn, but now that it's all centralized we can tweak this to suit.

*
*/
function convertToFlatpakPath(path: string) {
return join('/var/run/host', path)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 if there are cases where we shouldn't be applying this pattern let me know, ideally with the expected inputs and resulting paths. Having to adapt this behaviour based on the path type might make this a bit more complex, but I still think this approach is feasible...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/opt/ is the only path we don't need to apply this logic too

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh cool, you answered the question I just posted here #555 (comment) - thanks!

@shiftkey shiftkey marked this pull request as ready for review July 13, 2021 14:15
@Lunarequest
Copy link

Lunarequest commented Jul 13, 2021

unfortunately this is not able to detect binaries properly, also please add /usr/share/vscodium-bin/bin/codium to the vscodium detection path, this gets around the fact /usr/bin/codium is a symlink and this symlink is broken in /var/run

@Lunarequest
Copy link

Lunarequest commented Jul 13, 2021

Konsole is detected but vscodium isn't due to the issue mentioned here #555 (comment), you have to patch the launch code here

const exists = await pathExists(shell.path)
and over here
paths: ['/usr/bin/codium', '/var/lib/flatpak/app/com.vscodium.codium'],
add /usr/share/vscodium-bin/bin/codium so vscodium detection works as intended

@Lunarequest
Copy link

Lunarequest commented Jul 13, 2021

#556 fixes both issued mentioned above

@Lunarequest
Copy link

Editor detection is still broken, shell's are detected and launched with zero issues

@Lunarequest

This comment has been minimized.

@shiftkey shiftkey merged commit 478789f into linux Jul 14, 2021
@shiftkey shiftkey deleted the flatpak-abstractions branch July 14, 2021 14:53
shiftkey added a commit that referenced this pull request Jul 14, 2021
shiftkey added a commit that referenced this pull request Jul 19, 2021
shiftkey added a commit that referenced this pull request Jul 22, 2021
shiftkey added a commit that referenced this pull request Aug 13, 2021
shiftkey added a commit that referenced this pull request Aug 11, 2024
shiftkey added a commit that referenced this pull request Aug 11, 2024
shiftkey added a commit that referenced this pull request Aug 12, 2024
shiftkey added a commit that referenced this pull request Aug 12, 2024
shiftkey added a commit that referenced this pull request Aug 12, 2024
shiftkey added a commit that referenced this pull request Aug 14, 2024
shiftkey added a commit that referenced this pull request Aug 15, 2024
shiftkey added a commit that referenced this pull request Aug 17, 2024
shiftkey added a commit that referenced this pull request Aug 17, 2024
shiftkey added a commit that referenced this pull request Sep 2, 2024
shiftkey added a commit that referenced this pull request Sep 2, 2024
shiftkey added a commit that referenced this pull request Oct 30, 2024
shiftkey added a commit that referenced this pull request Nov 8, 2024
shiftkey added a commit that referenced this pull request Nov 8, 2024
shiftkey added a commit that referenced this pull request Nov 8, 2024
shiftkey added a commit that referenced this pull request Nov 8, 2024
shiftkey added a commit that referenced this pull request Nov 8, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Nov 11, 2024
shiftkey added a commit that referenced this pull request Feb 5, 2025
shiftkey added a commit that referenced this pull request Feb 5, 2025
shiftkey added a commit that referenced this pull request Feb 5, 2025
shiftkey added a commit that referenced this pull request Feb 5, 2025
shiftkey added a commit that referenced this pull request Feb 5, 2025
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.

2 participants