feat: add flatpak support to brewfile #21097
Conversation
Is this the default Flatpak repo? If so, I think it should not have to be specified, especially since most of your flatpak examples have no explicit remote refs. |
Good call, that is the default. I'll remove it from the example. |
MikeMcQuaid
left a comment
MikeMcQuaid
left a comment
There was a problem hiding this comment.
Thanks for the PR!
Some more questions:
- do you have example
Brewfiles for this? - can you describe why you're building this? Is it just for your personal use, your company's use, your distro's use, etc.? Just trying to get an understanding of how many people are wanting to use this and why. Hopefully you appreciate that adding ~1300 lines of code if it's mainly for your personal usage isn't going to work for us.
I do wonder if there's room for brew bundle to have its own extension system so it's easier/possible to maintain things like this in a Homebrew tap instead of in Homebrew/brew. Thoughts?
| def self.dump | ||
| remotes.map do |remote| | ||
| # Always include URL for flatpak remotes | ||
| "flatpak_remote \"#{remote[:name]}\", \"#{remote[:url]}\"" |
There was a problem hiding this comment.
I'm not sure I understand why we need both flatpak_remote and flatpack ..., remote:. Can you explain? Do you have some example Brewfiles that you are expecting to use or create?
Is a flatpak_remote useful without a flatpak (and vice versa)?
There was a problem hiding this comment.
I'm not sure I understand why we need both
flatpak_remoteandflatpack ..., remote:. Can you explain? Do you have some exampleBrewfiles that you are expecting to use or create?Is a
flatpak_remoteuseful without aflatpak(and vice versa)?
I was thinking of this in the same pattern as tap and brew. Just as all Homebrew formulae come from a tap, all flatpaks come from a remote. If we take the position that Flathub is the default remote (much like homebrew/core is the default tap), then:
flatpak_remoteis analogous totap- it registers a remote repositoryflatpakis analogous to brew - it installs a flatpak, specifying which remote withremote:- Most flatpaks would come from the default Flathub remote (just as most formulae come from homebrew/core)
- Custom remotes can be added with
flatpak_remote, and flatpaks from those remotes can be installed withflatpak "app.id", remote: "custom-remote"
A flatpak_remote without any flatpak entries would still be useful for setting up the remote (you might add flatpaks later). Similarly, flatpak entries without an explicit flatpak_remote would work fine as long as they were available in the default Flathub remote.
Here is the Brewfile I use on my development machine generated by brew bundle dump:
flatpak_remote "flathub", "https://dl.flathub.org/repo/"
tap "agammemnon/tap"
brew "shellcheck"
brew "actionlint"
brew "gcc"
brew "shfmt"
vscode "anykeyh.simplecov-vscode"
vscode "ban.spellright"
vscode "davidanson.vscode-markdownlint"
vscode "editorconfig.editorconfig"
vscode "foxundermoon.shell-format"
vscode "github.vscode-github-actions"
vscode "github.vscode-pull-request-github"
vscode "koichisasada.vscode-rdbg"
vscode "ms-azuretools.vscode-containers"
vscode "ms-azuretools.vscode-docker"
vscode "ms-python.debugpy"
vscode "ms-python.python"
vscode "ms-python.vscode-pylance"
vscode "ms-python.vscode-python-envs"
vscode "ms-vscode-remote.remote-containers"
vscode "ms-vscode-remote.remote-ssh"
vscode "ms-vscode-remote.remote-ssh-edit"
vscode "ms-vscode.makefile-tools"
vscode "ms-vscode.remote-explorer"
vscode "redhat.vscode-yaml"
vscode "shopify.ruby-lsp"
vscode "sorbet.sorbet-vscode-extension"
vscode "timonwong.shellcheck"
flatpak "com.discordapp.Discord"
flatpak "com.github.PintaProject.Pinta"
flatpak "com.github.rafostar.Clapper"
flatpak "com.github.tchx84.Flatseal"
flatpak "com.mattjakeman.ExtensionManager"
flatpak "com.obsproject.Studio"
flatpak "com.ranfdev.DistroShelf"
flatpak "com.slack.Slack"
flatpak "io.github.dvlv.boxbuddyrs"
flatpak "io.github.flattool.Ignition"
flatpak "io.github.flattool.Warehouse"
flatpak "io.github.gaheldev.Millisecond"
flatpak "io.github.getnf.embellish"
flatpak "io.github.kolunmi.Bazaar"
flatpak "io.gitlab.adhami3310.Impression"
flatpak "io.missioncenter.MissionCenter"
flatpak "io.podman_desktop.PodmanDesktop"
flatpak "me.iepure.devtoolbox"
flatpak "org.gnome.Calculator"
flatpak "org.gnome.Calendar"
flatpak "org.gnome.Characters"
flatpak "org.gnome.Connections"
flatpak "org.gnome.Contacts"
flatpak "org.gnome.DejaDup"
flatpak "org.gnome.FileRoller"
flatpak "org.gnome.Firmware"
flatpak "org.gnome.Logs"
flatpak "org.gnome.Loupe"
flatpak "org.gnome.Maps"
flatpak "org.gnome.NautilusPreviewer"
flatpak "org.gnome.Papers"
flatpak "org.gnome.SimpleScan"
flatpak "org.gnome.TextEditor"
flatpak "org.gnome.Weather"
flatpak "org.gnome.baobab"
flatpak "org.gnome.clocks"
flatpak "org.gnome.font-viewer"
flatpak "org.mozilla.Thunderbird"
flatpak "org.mozilla.firefox"
flatpak "org.openrgb.OpenRGB"
flatpak "page.tesk.Refine"
flatpak "sh.loft.devpod"
flatpak "us.zoom.Zoom"There was a problem hiding this comment.
Thanks! So you don't personally make use of any flatpack_remote beyond the default one (which I'd argue should be implicit like @gromgit did above)?
Library/Homebrew/.rubocop.yml
Outdated
| Naming/MethodParameterName: | ||
| AllowedNames: | ||
| - go | ||
| - flatpak |
There was a problem hiding this comment.
Are you sure this is needed?
There was a problem hiding this comment.
can you describe why you're building this?
Hi Mike, we ship homebrew by default in a family of Linux operating systems: Aurora, Bazzite, and Bluefin, total percentage is 1.99%, with about ~41k weekly device checkins
Our intent is to enable end users to be able to add their Flatpak gui apps to their Brewfiles so that there's just one file they can carry around with all their apps.
(Here's some back story, we're trying to round up volunteers around Linux brew users to help out, happy to discuss seperately! https://www.youtube.com/watch?v=viAuzuXir0U )
There was a problem hiding this comment.
@castrojo Good context, thanks!
@ahmedadan What's the failure without this line?
There was a problem hiding this comment.
I solved the issue and forgot to pull this out, it was an oversight on my end. I'll push a commit to resolve this shortly
|
Does it really need |
I'd have to refer to your expertise here, I can see the value of an abstraction like this especially for smaller or more niche tools, I think with a system like Flatpaks and their universality on Linux distributions I think it's at the scale where this could be warranted. If your hesitation is with maintaining this moving forward I'd definitely volunteer to do so if that would be any help. This also enables a level of curation for our family of distributions that would be invaluable. |
Yeh, I agree here. I think it makes sense for
Ok, good to know, I will CC you on relevant issues/PRs ❤️ |
That can definitely be done. What I was trying to avoid was the example below, which I find difficult to parse if each and every line needs to mention the remote by URL. brew "git"
brew "neovim"
# Install Flatpak applications
flatpak "org.gnome.Calculator", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.mozilla.firefox", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "com.spotify.Client", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.godotengine.Godot", remote: "https://flathub.org/beta-repo/flathub-beta.flatpakrepo"
flatpak "io.github.dvlv.boxbuddyrs", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.github.flattool.Ignition", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.github.flattool.Warehouse", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.github.gaheldev.Millisecond", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.github.getnf.embellish", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.github.kolunmi.Bazaar", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.gitlab.adhami3310.Impression", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.missioncenter.MissionCenter", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "io.podman_desktop.PodmanDesktop", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "me.iepure.devtoolbox", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Calculator", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Calendar", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Characters", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Connections", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Contacts", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.DejaDup", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.FileRoller", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Firmware", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Logs", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Loupe", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Maps", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.NautilusPreviewer", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.Papers", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.SimpleScan", remote: "https://flathub.org/repo/flathub.flatpakrepo"
flatpak "org.gnome.TextEditor", remote: "https://flathub.org/repo/flathub.flatpakrepo"Would either of you be open to FlatHub remaining the default and then only custom remotes using We then could have something like: flatpak "org.gnome.Calculator"
flatpak "org.mozilla.firefox"
flatpak "com.spotify.Client"
flatpak "org.godotengine.Godot", remote: "https://flathub.org/beta-repo/flathub-beta.flatpakrepo"
flatpak "io.github.dvlv.boxbuddyrs"
flatpak "io.github.flattool.Ignition"
flatpak "io.github.flattool.Warehouse"
flatpak "io.github.gaheldev.Millisecond"
flatpak "io.github.getnf.embellish"
flatpak "io.github.kolunmi.Bazaar"
flatpak "io.gitlab.adhami3310.Impression"
flatpak "io.missioncenter.MissionCenter"
flatpak "io.podman_desktop.PodmanDesktop"
flatpak "me.iepure.devtoolbox"
flatpak "org.gnome.Calculator"
flatpak "org.gnome.Calendar"
flatpak "org.gnome.Characters"
flatpak "org.gnome.Connections"
flatpak "org.gnome.Contacts"
flatpak "org.gnome.DejaDup"
flatpak "org.gnome.FileRoller"
flatpak "org.gnome.Firmware"
flatpak "org.gnome.Logs"
flatpak "org.gnome.Loupe"
flatpak "org.gnome.Maps"
flatpak "org.gnome.NautilusPreviewer"
flatpak "org.gnome.Papers"
flatpak "org.gnome.SimpleScan"
flatpak "org.gnome.TextEditor"Thoughts? @MikeMcQuaid @botantony |
Yeh, this seems good/appropriate for now 👍🏻 |
ahmedadan
force-pushed
the
feat/add-flatpak-to-brewfile
branch
2 times, most recently
from
ef17a37 to
be20d8e
Compare
ahmedadan
force-pushed
the
feat/add-flatpak-to-brewfile
branch
from
be20d8e to
02412e8
Compare
|
Hey folks, Flatpak / Flathub person here - this is super exciting to see, and a very cool addition to brew! If you can excuse the driveby, I did have a couple of pieces of feedback. Of course, your project your choice, feel free to take or leave. 🙇
There's one counter-example: if you use a .flatpakref file it basically encodes a remote + app tuple; in this case if you don't have that remote already, Flatpak adds the remote as
Thanks for reading! Hopefully you find this helpful. -Rob |
|
Thanks for the input Rob!
In the case of We don't want something added here that will make the
This doesn't really work for us as 1) it will not be possible to identify easily which invocation failed without output parsing and 2) this is different to how all other The common theme in the above: it's less important to map to how Flatpak does things as how |
No objections here! 😆 My team ends up teaching Git to highschoolers, and when there is more than one repo, things go south very quickly.
This makes sense. With that as the criteria, and expecting that 99.999% of installs will just want the apps off Flathub, maybe the least worst semantic is:
Fair enough! Just an optimization in any case. At the API level, you definitely can do discrete install operations without the hooks/pruning, but I'm not immediately seeing that on the CLI. And I entirely appreciate that accessing the Flatpak API is not a practical approach here!
👌 |
Ooof, good job, rather you than me!
This makes sense to me. @ahmedadan thoughts? |
|
Thanks for the thoughtful discussion @ramcq @MikeMcQuaid! I really like where this landed. The 3-tier approach makes a lot of sense, just to make sure I understand we're looking at the following: # Tier 1: Flathub (default)
flatpak "org.gnome.Calculator"
# Tier 2: Single-app remote - creates "org.godotengine.Godot-origin"
flatpak "org.godotengine.Godot", remote: "https://dl.flathub.org/beta-repo/"
# Tier 3: Named shared remote - creates "flathub-beta" if not exists
flatpak "org.godotengine.Godot", remote: "flathub-beta", url: "https://dl.flathub.org/beta-repo/"
flatpak "io.github.dvlv.boxbuddyrs", remote: "flathub-beta" # reuses existing remoteThe dumper will detect the remote type and output the appropriate format:
One question: for Tier 3, should we validate that the Options:
I'm leaning toward (1) for safety with flexibility. Thoughts? |
|
@ahmedadan All sounds good to me! |
6 participants
brew lgtm(style, typechecking and tests) with your changes locally?Adds support for Flatpak applications and remotes in Brewfile. This change extends Brewfile to support managing Flatpak applications and remotes, making it easier to maintain a consistent set of installed applications across Linux systems.
Sample Brewfile
Bundle Commands
All Brewfile commands now support Flatpak operations:
Implementation Details
Closes #21029