Skip to content
This repository was archived by the owner on Apr 5, 2022. It is now read-only.

(Ethos) Dev Experience

Jump to bottom
Michael Bullington edited this page Mar 9, 2021 · 4 revisions

Dev Experience

Since OSTree is an immutable system, this presents a problem to developers and others who want to install custom software outside of Snaps. Solutions exist such as containers (Toolbox), layering over a system (Linuxbrew), etc...

Core tenants should be:

  • Users have access to wide variety of packages.
  • Packages should be up-to-date, potentially more-so than the underlying system.
  • Supports usecases we didn't think of:
    • Example: how would a software dev install ROS (Robot Operating System, not a real OS) on their machine?
    • What about things like Tensorflow?
  • Host vs. dev context should never be surprising.
  • SDKs must work in Snap IDEs such as VSCode, CLion, etc...

Prior Art

Toolbox vs. Linuxbrew

Linuxbrew

Pros:

  • Wide variety of packages.
  • Familiar for those coming from macOS.
  • 'Just works' in IDEs.

Cons:

  • ABI compatibility can be surprising, especially with pkg-config. Figuring out which context you're in can be very difficult.
  • Packages are very macOS-centric, as one might expect. There are awesome people working on Linuxbrew specifically, but things like swift don't work.

Toolbox w/ Ubuntu base

Pros:

  • ABI compatibility is 1/1 and never surprising.
  • SDKs would work in IDEs because we could just break into the container's file system (no need to worry about ABI).

Cons:

  • Limited package availability for Ubuntu (sounds crazy).
    • PPAs are often rabbit holes and Debian packaging can be prohibitively complex.
  • Since we're on an LTS release (even if we weren't), packages could get way behind what devs need.
  • Unable to do things like xdg-open inside the container.

Toolbox w/ Arch Linux base

Pros:

  • Containerizing Arch Linux makes ABI incompatibility (see Cons) unsurprising.
  • Lots of packages, all guaranteed to work on Linux.
    • Big win here.
    • A crazy amount of source packages are on the AUR if not official repos.

Cons:

  • pacman CLI has steep learning curve:
    • Really nice once you get the hang of it
    • This is about 50 copy-pastes later
  • Very small ABI compatibility.
  • Unable to do things like xdg-open inside the container.
  • IDEs may have trouble.

Solution

Providing users with as much flexibility as possible is (right now, for me) the most important. If we choose containerizing Arch Linux, I think we can develop around the cons and make it "Just work" for users.

workbench:

I don't think we should use Fedora Toolbox. It relies heavily on podman, which seems like bringing in a large un-needed part of our system. I'd much prefer to use systemd-nspawn and build a wrapper around that.

For me: https://serverfault.com/questions/995562/bind-mount-with-systemd-nspawn

  • Installs Arch Linux based image and puts it in the users' ~/.workbench directory.
    • We need our own repo to make the experience a little nicer on the Arch end. Mostly cosmetic like setting pleasant defaults.
    • This looks like a great repo to add as well: https://github.com/arch4edu/arch4edu
    • https://wiki.manjaro.org/index.php/Pamac provides a user-friendly CLI that looks like Homebrew.
      1. pamac seems like such an odd name. Is it bike-shedding to symlink it to pac?
  • After installed, Workbench will start on login.
  • We can have pretty tight integration between Workbench and other parts of the system.
    • Market can have "Dev Starters" that install both great apps and great Arch packages for a particular language.
      1. Highly inspired by VSCode Dev Containers
    • I really like how Windows Terminal can choose between PowerShell, Ubuntu, etc... If Workbench is installed, we can prompt the user to make that default. If they say yes, you can click on More -> New Local Terminal to open a regular term, default is Workbench.~

open:

If a user wanted to open a file in ~/Downloads from Workbench, what would they do?

open basically combines xdg-open and flatpak-spawn --host. It will try running locally, then if that fails connect to a DBus service and have the service try (which would always be on the host). The name open also has the added benefit of being intuitive to macOS users.

So in both host and Workbench this would do as expected:

open ~/Downloads

And in the Workbench, you could run a command on the host by doing:

open -a env -- WAYLAND_DISPLAY=1 something

The Snap issue:

For example the VSCode snap (which uses classic confinement). How can I specify a Flutter SDK, GOROOT, etc I know will work?

Investigate:

  • If we mount /snap and /var/lib/snapd to the container, could we run classic confinement snaps inside Workbench? This would solve basically all issues.

Clone this wiki locally