modrinth / code

The Modrinth monorepo containing all code which powers Modrinth!
https://modrinth.com
Other
861 stars 149 forks source link

Packaging solutions #497

Open intergrav opened 1 year ago

intergrav commented 1 year ago

At the time of writing, there are only two official ways for using the Modrinth App on Linux - AppImages and Debian packages. While this is fine for people on Debian-based distributions, and those who like using AppImages, some may prefer to use a package manager such as flatpak or dnf as it's easier to manage packages that way. According to this comment, the current compiled Debian packages aren't very great right now because they don't include proper dependency info and leave out some important stuff.

Along with AppImages and Debian packages, there are various packaging solutions to consider. If there's other packaging types that you think would be a good idea, suggest them in this thread. I personally think that the Flatpak should be maintained by Modrinth, and the rest could be maintained by members of the community if they wanted to do so. I think this is especially important as the Modrinth App is now in an open beta.

This issue serves as a place to discuss packaging, and I'll also treat this as a sort of "unofficial download page" for Linux users with updated information on what packages to use and where to get them.

Indicators

  1. a package exists and works properly
  2. that package is considered ready for daily use
  3. that package is available on commonly used repositories, such as a Flatpak being on Flathub for example

🔃

  1. same as 1 and 2 in the above
  2. however, that package is not available on commonly used repositories, but is available on a developer's personal repository. this may not be applicable for some solutions and will use the checkmark icon instead, such as COPR

Unix/Unix-like packaging

Flathub logo Flatpak

Package is available and maintained on Flathub - thank you @getchoo and other contributors!

Package that can be used on most common Linux distributions, and also good for security as Flatpaks are sandboxed unlike other types. This will be the package that most Linux users are looking for. ###### Notable mentions/issues - https://github.com/tauri-apps/tauri/issues/3619 (@Hyphrio) - May be tricky to upload to Flathub, see [this comment](https://github.com/modrinth/theseus/issues/497#issuecomment-1666737825) ###### Who's working on this? - @getchoo is currently working on a package https://github.com/modrinth/theseus/pull/559 - @getchoo opened a PR for Flathub https://github.com/flathub/flathub/pull/4950

Arch

Packages are available and maintained on the AUR - modrinth-app and modrinth-app-bin - thank you Antti!

###### Any ideas on this? - @offbeat-stuff suggested making a PKGBUILD that extracts the `deb` package to be used as an Arch pacman package. [Here's an example](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-xanmod-linux-bin-x64v3) ###### Notable mentions/issues - https://github.com/tauri-apps/tauri/issues/3728 (@Hyphrio) - https://github.com/tauri-apps/tauri/pull/4301 (@Hyphrio) ###### Who's working on this? - [Antti](https://aur.archlinux.org/account/Antti) has made two AUR packages - `modrinth-app` - `modrinth-app-bin` - [Nixuge](https://aur.archlinux.org/account/Nixuge) has made two AUR packages, however they could be broken as they miss many dependencies - `modrinth-app-git` - `modrinth-cli-git`

Nix logo Nix

Package is available and maintained on Nixpkgs - modrinth-app - thank you @getchoo and other contributors!

Nix can be used on both Linux and Darwin systems and is the package manager for NixOS. ###### Who's working on this? - @getchoo has a PR in nixpkgs https://github.com/NixOS/nixpkgs/pull/289149 - @getchoo is also working on a Nix flake https://github.com/modrinth/theseus/pull/561

Fedora logo Fedora Copr

User-maintained package repositories for Fedora, CentOS Stream, and RHEL. Can be enabled with `dnf copr enable /` ###### Notable mentions/issues - https://github.com/tauri-apps/tauri/issues/4402 (@Hyphrio) - May be difficult, see [this comment](https://github.com/modrinth/theseus/issues/497#issuecomment-1666737825)

Homebrew logo Homebrew cask

Homebrew is a package manager for MacOS (and Linux). Idea from https://github.com/modrinth/theseus/issues/560. It would allow for easy installation on MacOS.

Windows packaging

🔃 🍨 Scoop

Package is available and maintained on brawaru/bucket - thank you @brawaru!

Scoop is a command-line installer for Windows. It has many benefits, such as installing packages in a portable way (by default, it installs packages to `~/scoop`). Package manifests are just simple JSON files - this shouldn't be too hard to set up.

WinGet logo WinGet

Package is available and maintained on WinGet - thank you @TheBossMagnus and other contributors!

WinGet is Microsoft's own package manager.

Other information

Theseus is very complex to package and doing so for many different formats at a time would be a little chaotic. I think that the common package types like Flatpak, Arch and Nix packages should be done.

Leave your thoughts below!

For discussion, see the thread in the #development channel of the Modrinth Discord. You can also continue discussing here if you prefer that.
Hyphrio commented 1 year ago

For Linux these two Tauri issues are related: https://github.com/tauri-apps/tauri/issues/4402 https://github.com/tauri-apps/tauri/issues/3619

offbeat-stuff commented 1 year ago

At least make a PKGBUILD that extracts the deb package to be used as an archlinux pacman package.

offbeat-stuff commented 1 year ago

Here is a PKGBUILD for archlinux that extracts a .deb package

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-xanmod-linux-bin-x64v3

getchoo commented 1 year ago

At least make a PKGBUILD that extracts the deb package to be used as an archlinux pacman package.

this isn't a good method for the long term, especially as arch is known to make abi incompatible changes to packages frequently, or at the very least push versions of libraries usually incompatible with those found on debian/ubuntu based distros (there are also problems between those, but usually less so). here's a good example

for a temporary thing it would probable be fine? but ideally all community packages should be built against their distro's packages to ensure the final binaries actually work

getchoo commented 1 year ago

I personally think that the Flatpak should be maintained by Modrinth, and the rest could be maintained by members of the community if they wanted to do so.

i 100% agree with this. it's very hard and completely impractical for upstream to support the endless amounts of linux distributions out there; universal solutions should be the main focus here, along with basic files for distribution that can be used there and in downstream packages

Flatpak/Flathub

the biggest issue here is that networking may need to be enabled during building due to flatpak's build tools lacking support for pnpm lock files. this is a problem since flathub doesn't really like that and it could make it very difficult for it to be uploaded there

Nixpkgs

this is pretty much complete and fully working on any linux distro. macos support for is being worked on. the problem with pnpm and offline builds also showed up here, but since nix is a lot more flexible with it's build process, i was able to figure out a way to maintain reproducibility while still using pnpm's lock file. i will try to upstream this in nixpkgs once a stable release is made

Fedora Copr Arch User Repository Alpine Linux packages

like you said, these should probably be community packages. i would like to note though that some may be difficult (mainly fedora rpms) due to the issue with pnpm and offline builds as mentioned before. arch is very lose with this though so it should work fine; i can't say anything about alpine since i've never used/packaged for it personally

the only other thing i would like to note is that tauri's native package export feature really shouldn't be used here. the current debian package for example seems to strip out the other tools theseus provides such as it's cli, doesn't include dependency information (i'm assuming the direct dependencies of theseus are compiled statically...which isn't great but works ig) which can cause issues with even launching minecraft, and in general is very inflexible for the future where manual intervention for packaging may be required. i'm shocked the deb package works in it's current state, let alone if it can even actually start minecraft ootb. we should be following the standard of other linux packages (specifically packages for other launchers) by supporting the formats themselves instead of relying on a tool that in all honestly, doesn't produce good packages. most of this will fall on the community of individual distros, but for a download link on the upstream maintainer's website, poorly auto generated debs and appimages aren't really acceptable for "linux support" imo. the best solution to fix this is flatpak

edit: macos support for nix is available now. discussion about upstreaming to nixpkgs will be in https://github.com/NixOS/nixpkgs/issues/247468 (thanks PC!)

Hyphrio commented 1 year ago

Tauri issue and PR for Arch Linux: https://github.com/tauri-apps/tauri/issues/3728 https://github.com/tauri-apps/tauri/pull/4301 PR seems to be related for Pacman but seems to have stalled

CompeyDev commented 1 year ago

I'd be willing to draft PKGBUILDs for the AUR, just lmk.

TheoCGaming commented 1 year ago

If you do go for Flatpak, please, PLEASE include proper permissions. I'm tired of having to deal with broken permissions on Flatpak packages.

MagmaBro123 commented 1 year ago

If you do go for Flatpak, please, PLEASE include proper permissions. I'm tired of having to deal with broken permissions on Flatpak packages.

Flatseal can help with fixing those, but agreed.

intergrav commented 1 year ago

Flatseal can help with fixing those, but agreed.

The user shouldn't have to use Flatseal to fix broken permissions provided by the package, that's just bad design

MagmaBro123 commented 1 year ago

Flatseal can help with fixing those, but agreed.

The user shouldn't have to use Flatseal to fix broken permissions provided by the package, that's just bad design

Again, I said I agreed

blt-r commented 1 year ago

There is a tool to generate flatpak builder sources definitions from package-lock.json or yarn.lock, but it doesn't support pnpm-lock.yaml. The only way I found to convert pnpm-lock.yaml to something that the tool can consume is this npm package, but I didn't manage to make it work. We need to get either yarn or npm lockfile with right dependency versions. (Or implement support for pnpm in that tool, but that's very not easy).

Besides that, we probably will need to disable auto updating for the flatpak package. If there is no better way, that could be done with some sed in the build script.

Since the whole app is bundled in a single executable, packaging it as a flatpak would probably be pretty easy.

blt-r commented 1 year ago

Actually, on a closer look, the resulting binary has quite a few dynamic dependencies. I'll try to see if I can put all of them into the flatpak

intergrav commented 1 year ago

I just made a forum thread in the Modrinth Discord server #development channel for discussing about this: https://discord.com/channels/734077874708938864/1138510665947041876 I'll also edit the issue and place it around the top, you can continue discussing here aswell :)

AnOpenSauceDev commented 1 year ago

3 days and still no mention of snap... /s

MagmaBro123 commented 1 year ago

Ew, Snaps.

getchoo commented 1 year ago

https://discord.com/channels/734077874708938864/1138510665947041876

quoting a message i made here:

nix packaging for linux and darwin is basically complete, just needs a few little touchups. i have flatpak almost working, but as it stands it would only be able to be distributed through flathub - only the website. this is due to no flatpak build tools supporting pnpm’s lockfile format; it’s a similar case with nix, but there are a few diy methods already in nixpkgs i was able to use so not an issue there. for flatpak, networking needs to be enabled during the build but that’s a big nono

only other “issue” is that tauri (or what i’m hoping to be only the specific version of tauri being used) is using an old version of webkitgtk to build so…i need to compile all of webkitgtk for it to work, which causes my pc to oom

it seems that upstream is willing to switch to npm (source) which solves the first issues; everything else with the flatpak seems pretty good.

one thing i thought of though was making some packaging guidelines for the app, as currently some things such as actual naming can be unclear. maybe this could be done with upstream sources for stuff like desktop files?

MagmaBro123 commented 1 year ago

https://discord.com/channels/734077874708938864/1138510665947041876

quoting a message i made here:

nix packaging for linux and darwin is basically complete, just needs a few little touchups. i have flatpak almost working, but as it stands it would only be able to be distributed through flathub - only the website. this is due to no flatpak build tools supporting pnpm’s lockfile format; it’s a similar case with nix, but there are a few diy methods already in nixpkgs i was able to use so not an issue there. for flatpak, networking needs to be enabled during the build but that’s a big nono

only other “issue” is that tauri (or what i’m hoping to be only the specific version of tauri being used) is using an old version of webkitgtk to build so…i need to compile all of webkitgtk for it to work, which causes my pc to oom

it seems that upstream is willing to switch to npm (source) which solves the first issues; everything else with the flatpak seems pretty good.

one thing i thought of though was making some packaging guidelines for the app, as currently some things such as actual naming can be unclear. maybe this could be done with upstream sources for stuff like desktop files?

You and the Modrinth team would probably be better at chatting about how this would work imo. I mostly broght up Flatpak due to it being more secure thanks to its sandboxed nature.

And, Snaps also suck, Debs are kinda the stone-age of package formats, and AppImages are kinda annoying due to you having to manually download each new AppImage per update. Also, both the Deb and AppImage Modrinth provides seem to be quite buggy. At least, afaik.

AnOpenSauceDev commented 1 year ago

And, Snaps also suck, Debs are kinda the stone-age of package formats, and AppImages are kinda annoying due to you having to manually download each new AppImage per update. Also, both the Deb and AppImage Modrinth provides seem to be quite buggy. At least, afaik.

I was joking about snaps (unfortunately Canonical isn't), and I've had tonnes of issues with installing the DEB version at all, plus packaging systems that bundle everything like AppImages and Flatpak tend to take up more space than native (10x more for the modrinth app), which might be an issue for some people.

MagmaBro123 commented 1 year ago

And, Snaps also suck, Debs are kinda the stone-age of package formats, and AppImages are kinda annoying due to you having to manually download each new AppImage per update. Also, both the Deb and AppImage Modrinth provides seem to be quite buggy. At least, afaik.

I was joking about snaps (unfortunately Canonical isn't), and I've had tonnes of issues with installing the DEB version at all, plus packaging systems that bundle everything like AppImages and Flatpak tend to take up more space than native (10x more for the modrinth app), which might be an issue for some people.

Eh, true. But there's no real universal way of packaging apps easily.

getchoo commented 1 year ago

Flatpak tend to take up more space than native (10x more for the modrinth app),

this is basically a made up number. in fact, most of modrinth app's dependencies are already in the runtime - this means unlike some flatpaks, there are very few dependencies specific to it that need to be bundled. it should be a similar size to the deb + the size of the runtime

MagmaBro123 commented 1 year ago

https://www.youtube.com/watch?v=IYXlgzrZRIE

AnOpenSauceDev commented 1 year ago

Flatpak tend to take up more space than native (10x more for the modrinth app),

this is basically a made up number. in fact, most of modrinth app's dependencies are already in the runtime - this means unlike some flatpaks, there are very few dependencies specific to it that need to be bundled. it should be a similar size to the deb + the size of the runtime

I was more talking about the appimage, I'm aware that flatpak has measures to keep its size down.

cryolithic commented 1 year ago

I'll add that flatpak is what the Steam Deck is using, so that's a big gaming base there

AnOpenSauceDev commented 1 year ago

I'll add that flatpak is what the Steam Deck is using, so that's a big gaming base there

flatpak is supported by almost all modern distros in general, but the deck can run the AppImage.

intergrav commented 1 year ago

Added getchoo's two PRs to the issue

I've also added a section for this Homebrew issue:

offbeat-stuff commented 1 year ago

no arm64 support sad

offbeat-stuff commented 1 year ago

ok fair other launchers dont support arm too

AnOpenSauceDev commented 1 year ago

ok fair other launchers dont support arm too

MultiMC5 has a few ARM forks iirc.

no arm64 support sad

it wouldn't be impossible to compile this for an ARM64 machine, but most of these devices have a small gaming userbase, have different natives that aren't mature, etc, etc. But I'm pretty sure you can just paste the .mrpack into MultiMC, and run it that way.

you might be able to use the GUI (no clue about in-game performance) if you emulate via UTM or QEMU on an M1 Mac, but i have doubts about compatibility.

getchoo commented 1 year ago

no arm64 support sad

the nix package can build for arm and has already in ci (see here). i don't have an arm desktop or anything to actually test it on, but it should work unless tauri is incompatible

getchoo commented 1 year ago

also posting this here from discord for aur builds:

i've made a patch for modrinth-app-git that should let it build. i don't run arch personally, so i can't really test it (hey twice i've said that now!), but anyone who runs arch might want to check it out and send it to the maintainer

click for patch ```diff diff --git a/PKGBUILD b/PKGBUILD index c955fb2..44c7be8 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -2,7 +2,7 @@ pkgname=modrinth-app-git _gitname=theseus -pkgver=r147.3f46882 +pkgver=v0.4.0.r3.g5f0d44a pkgrel=1 pkgdesc='Official Modrinth launcher. Open-source, built by the community, for the community.' url=https://github.com/modrinth/theseus @@ -10,34 +10,64 @@ arch=(x86_64) license=(GPL3) conflicts=('modrinth-app') provides=('modrinth-app') -makedepends=('cargo-tauri' 'yarn' 'pnpm') +makedepends=('cargo' 'pnpm' 'git') +# tauri deps +depends=('openssl' 'dbus' 'freetype2' 'gtk3' 'libappindicator-gtk3' 'librsvg' 'libsoup' 'webkit2gtk' + # minecraft deps + 'libgl' 'libpulse' 'libx11' 'libxcursor' 'libxext' 'libxxf86vm') +optdepends=( + 'xorg-xrandr: for older minecraft versions' +) source=("git+https://github.com/modrinth/theseus") sha256sums=('SKIP') pkgver() { - cd "${srcdir}/${_gitname}" - printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)" + cd "$_gitname" + + git describe --long --tags --abbrev=7 | sed 's/\([^-]*-g\)/r\1/;s/-/./g' +} + +prepare() { + cd "$_gitname" + + export RUSTUP_TOOLCHAIN=stable + cargo fetch --locked --target "$CARCH-unknown-linux-gnu" + + cd "theseus_gui" + pnpm install --frozen-lockfile --no-optional } build() { - cd "${srcdir}/${_gitname}/theseus_gui/" + cd "$_gitname/theseus_gui/" + + pnpm build - # Bundle the deb only as it takes no time (unlike the appimage) - # & contains every folder at their right place ready to go - sed -i -E \ - "s|\"targets\": \"all\"|\"targets\": \"deb\"|" \ - "src-tauri/tauri.conf.json" + cd .. - yarn install - cargo tauri build + export RUSTUP_TOOLCHAIN=stable + export CARGO_TARGET_DIR=target + cargo build --frozen --release --all-features +} + +check() { + cd "$_gitname" + + export RUSTUP_TOOLCHAIN=stable + cargo test --frozen --all-features } package() { - # Grab the folder name (has the version embeeded in it) - folder=$(find . -type d -name "modrinth-app*") 2>/dev/null + cd "$_gitname" + + mkdir -p "$pkgdir"/usr/{bin,share/{applications,icons/hicolor/256x256/apps}} + + pushd target/release + for bin in theseus_*; do + install -Dm755 "$bin" "$pkgdir"/usr/bin/"$bin" + done + popd - # Then just copy everything from the deb bundle folder - cp -r "${folder}/data/usr/" \ - "${pkgdir}" + install -Dm644 theseus_gui/src-tauri/icons/Square284x284Logo.png "$pkgdir"/usr/share/icons/hicolor/256x256/apps/com.modrinth.ModrinthApp.png + #install -Dm644 distribution/com.modrinth.ModrinthApp.desktop "$pkgdir"/usr/share/applications/com.modrinth.ModrinthApp.desktop } ```
CompeyDev commented 1 year ago

also posting this here from discord for aur builds:

i've made a patch for modrinth-app-git that should let it build. i don't run arch personally, so i can't really test it (hey twice i've said that now!), but anyone who runs arch might want to check it out and send it to the maintainer click for patch

diff --git a/PKGBUILD b/PKGBUILD
index c955fb2..44c7be8 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -2,7 +2,7 @@

pkgname=modrinth-app-git
_gitname=theseus
-pkgver=r147.3f46882
+pkgver=v0.4.0.r3.g5f0d44a
pkgrel=1
pkgdesc='Official Modrinth launcher. Open-source, built by the community, for the community.'
url=https://github.com/modrinth/theseus
@@ -10,34 +10,64 @@ arch=(x86_64)
license=(GPL3)
conflicts=('modrinth-app')
provides=('modrinth-app')
-makedepends=('cargo-tauri' 'yarn' 'pnpm')
+makedepends=('cargo' 'pnpm' 'git')
+# tauri deps
+depends=('openssl' 'dbus' 'freetype2' 'gtk3' 'libappindicator-gtk3' 'librsvg' 'libsoup' 'webkit2gtk'
+ # minecraft deps
+ 'libgl' 'libpulse' 'libx11' 'libxcursor' 'libxext' 'libxxf86vm')
+optdepends=(
+ 'xorg-xrandr: for older minecraft versions'
+)
source=("git+https://github.com/modrinth/theseus")
sha256sums=('SKIP')

pkgver() {
- cd "${srcdir}/${_gitname}"
- printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)"
+ cd "$_gitname"
+
+ git describe --long --tags --abbrev=7 | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
+}
+
+prepare() {
+ cd "$_gitname"
+
+ export RUSTUP_TOOLCHAIN=stable
+ cargo fetch --locked --target "$CARCH-unknown-linux-gnu"
+
+ cd "theseus_gui"
+ pnpm install --frozen-lockfile --no-optional
}

build() {
- cd "${srcdir}/${_gitname}/theseus_gui/"
+ cd "$_gitname/theseus_gui/"
+
+ pnpm build

- # Bundle the deb only as it takes no time (unlike the appimage)
- # & contains every folder at their right place ready to go
- sed -i -E \
-     "s|\"targets\": \"all\"|\"targets\": \"deb\"|" \
-     "src-tauri/tauri.conf.json"
+ cd ..

- yarn install
- cargo tauri build
+ export RUSTUP_TOOLCHAIN=stable
+ export CARGO_TARGET_DIR=target
+ cargo build --frozen --release --all-features
+}
+
+check() {
+ cd "$_gitname"
+
+ export RUSTUP_TOOLCHAIN=stable
+ cargo test --frozen --all-features
}

package() {
- # Grab the folder name (has the version embeeded in it)
- folder=$(find . -type d -name "modrinth-app*") 2>/dev/null
+ cd "$_gitname"
+
+ mkdir -p "$pkgdir"/usr/{bin,share/{applications,icons/hicolor/256x256/apps}}
+
+ pushd target/release
+ for bin in theseus_*; do
+     install -Dm755 "$bin" "$pkgdir"/usr/bin/"$bin"
+ done
+ popd

- # Then just copy everything from the deb bundle folder
- cp -r "${folder}/data/usr/" \
-     "${pkgdir}"
+ install -Dm644 theseus_gui/src-tauri/icons/Square284x284Logo.png "$pkgdir"/usr/share/icons/hicolor/256x256/apps/com.modrinth.ModrinthApp.png
+ #install -Dm644 distribution/com.modrinth.ModrinthApp.desktop "$pkgdir"/usr/share/applications/com.modrinth.ModrinthApp.desktop
}

Checking it our right now.

CompeyDev commented 1 year ago

Apparently it's corrupt?

image

CompeyDev commented 1 year ago

Apparently it's corrupt?

image

Oh I realized that there's a insertions/deletions summary on line 7 for some reason haha.

CompeyDev commented 1 year ago

It works perfectly fine!

image

AnOpenSauceDev commented 1 year ago

no arm64 support sad

the nix package can build for arm and has already in ci (see here). i don't have an arm desktop or anything to actually test it on, but it should work unless tauri is incompatible

Currently building this from source on my Raspberry PI.

AnOpenSauceDev commented 1 year ago

after compiling for... 7 hours... gio failed to build and panicked. I'll try doing this again.

CompeyDev commented 1 year ago

after compiling for... 7 hours... gio failed to build and panicked. I'll try doing this again.

I feel your pain. Truly.

AnOpenSauceDev commented 1 year ago

I feel your pain. Truly.

This is the way of rustc...

after compiling for... 7 hours... gio failed to build and panicked. I'll try doing this again. (huge mistake)

even with a ludicrous amount of swap space it failed yet again, this time with a glib error.

Warning! very big ANSI text file! ``` ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m x11 v2.21.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m dunce v1.0.4 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m zstd-safe v5.0.2+zstd.1.5.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m glob v0.3.1 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m httpdate v1.0.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tower-service v0.3.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tauri-utils v1.4.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tokio-util v0.7.8 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m pango v0.15.10 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m cairo-rs v0.15.12 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m h2 v0.3.20 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m atk v0.15.1 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tokio-native-tls v0.3.1 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m gdkx11-sys v0.15.1 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m x11-dl v2.21.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m raw-window-handle v0.5.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m fdeflate v0.3.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m sha1 v0.10.5 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m hyper v0.14.27 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m hyper-tls v0.5.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m serde_urlencoded v0.7.1 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tracing-log v0.1.3 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m sharded-slab v0.1.4 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m tao v0.16.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m encoding_rs v0.8.32 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m hex v0.4.3 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m mime v0.3.17 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m ipnet v2.8.0 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m base64 v0.21.2 ^[[0m^[[0m^[[1m^[[32m Compiling^[[0m reqwest v0.11.18 ^[[0m^[[0m^[[1m^[[31merror^[[0m^[[1m:^[[0m could not compile `glib` (lib) Caused by: process didn't exit successfully: `rustc --crate-name glib --edition=2021 /build/cargo-vendor-dir/glib-0.15.12/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,fut> ^[[0m^[[0m^[[1m^[[33mwarning^[[0m^[[1m:^[[0m build failed, waiting for other jobs to finish...```
AnOpenSauceDev commented 1 year ago

looks like --edition is being forced as 2021 when glib only has a 2018 or 2015 edition: error: argument for --edition must be one of: 2015|2018. (instead was 2021)

getchoo commented 1 year ago

after compiling for... 7 hours... gio failed to build and panicked. I'll try doing this again.

build with nix build --accept-flake-config github:getchoo/nix-exprs#modrinth-app. this will let you use my binary cache to avoid compiling, since everything is reproducible (outside of hardware issues ofc :p)

AnOpenSauceDev commented 1 year ago

build with nix build --accept-flake-config github:getchoo/nix-exprs#modrinth-app. this will let you use my binary cache to avoid compiling, since everything is reproducible (outside of hardware issues ofc :p)

When i try to run this, i get error: unable to execute '/nix/store/08kixl87lyjkakvg98vfkvz0yf26dwig-modrinth-app-unstable-2023-08-06/bin/modrinth-app-unstable': No such file or directory, and i think it might just be easier on my sanity to cross-compile or simulate a more powerful ARM device on my personal server.

AnOpenSauceDev commented 1 year ago

Nix logo Nixpkgs

Large package repository. Nix can be used on both Linux and Darwin systems, and is the package manager for NixOS. While Flatpaks can be used on NixOS, Flatpak goes against it's reproducibility.

Who's working on this?
* @getchoo already has a working package. Will be in nixpkgs when Theseus is stable.

  * NixOS: `nix shell github:getchoo/nix-exprs#theseus` and then `theseus_gui`
  * Non-NixOS and Darwin (untested, but should work): `nix shell github:getchoo/nix-exprs#theseus` and then `nix run --impure github:guibou/nixGL -- theseus_gui`

* @getchoo is also working on a Nix flake [feat: add nix flake #561](https://github.com/modrinth/theseus/pull/561)

@intergrav theseus is now modrinth-app. Source, you might want to change nix shell github:getchoo/nix-exprs#theseus to nix shell github:getchoo/nix-exprs#modrinth-app to reflect on that.

getchoo commented 1 year ago

build with nix build --accept-flake-config github:getchoo/nix-exprs#modrinth-app. this will let you use my binary cache to avoid compiling, since everything is reproducible (outside of hardware issues ofc :p)

~ When i try to run this, i get error: unable to execute '/nix/store/08kixl87lyjkakvg98vfkvz0yf26dwig-modrinth-app-unstable-2023-08-06/bin/modrinth-app-unstable': No such file or directory, and i think it might just be easier on my sanity to cross-compile or simulate a more powerful ARM device on my personal server. ~

i think this might be because of the naming of the package and nix thinking it's also the name of the binary. try doing nix shell --accept-flake-config github:getchoo/nix-exprs#modrinth-app and then run modrinth-app

AnOpenSauceDev commented 1 year ago

i think this might be because of the naming of the package and nix thinking it's also the name of the binary. try doing nix shell --accept-flake-config github:getchoo/nix-exprs#modrinth-app and then run modrinth-app

I figured that out not too long after, but the natives are still building from the nix run after 9 hours, and sunk-cost fallacy is preventing me from restarting so my overclock takes effect.

intergrav commented 1 year ago

@intergrav theseus is now modrinth-app. Source, you might want to change nix shell github:getchoo/nix-exprs#theseus to nix shell github:getchoo/nix-exprs#modrinth-app to reflect on that.

Should I also change theseus-gui to modrinth-app-gui?

TheoCGaming commented 1 year ago

Probably a good idea so it's a little easier to search for.

getchoo commented 1 year ago

Should I also change theseus-gui to modrinth-app-gui?

no, the main binary is installed as modrinth-app

nixos users should also be able to just select the desktop icon now if it's installed through nix profile, home manager, a system configuration, etc.

AnOpenSauceDev commented 1 year ago

Should I also change theseus-gui to modrinth-app-gui?

No, the gui package is still called theseus_gui, at least for now.

triphora commented 1 year ago

When packaged, the GUI should always be modrinth-app. If we decide to launch the CLI at a later date, that will be modrinth-app-cli.