build: add a nix flake to build and run DanXi on NixOS#676
build: add a nix flake to build and run DanXi on NixOS#676sseu-buhzzi wants to merge 12 commits into
Conversation
This is needed when using `nix develop -c flutter build apk`, for that it overwrites `local.properties`.
Examples are `nix develop . -c flutter build apk`, `nix develop . -c flutter run -d linux`, or `nix run`
sseu-buhzzi
changed the title
|
Sorry for the delay. I would review it tomorrow asap. |
w568w
added
enhancement
There was a problem hiding this comment.
Pull request overview
Adds Nix support for DanXi by introducing a flake-based build/dev environment (Linux desktop build + Android dev tooling), along with README documentation and a small Gradle change to allow locating Flutter via an environment variable.
Changes:
- Add
flake.nix/flake.lockand Nix expressions for building the Linux desktop app and providing a devShell with Android/Chrome tooling. - Update Android Gradle settings to allow using
FLUTTER_ROOT(useful for Nix dev shells / shims). - Document NixOS/Nix flake usage in both Chinese and English READMEs and ignore Nix build outputs.
Reviewed changes
Copilot reviewed 9 out of 11 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| README.md | Adds NixOS usage instructions and flake build commands (CN). |
| README_EN.md | Adds NixOS usage instructions and flake build commands (EN). |
| nix/util/hex-to-base36.nix | Adds a Nix helper wrapper for hex→base36 conversion via Python. |
| nix/util/hex_to_base36.py | Adds the Python implementation of hex→base36 conversion. |
| nix/packages/default.nix | Defines the flake package build for the Flutter Linux desktop app. |
| nix/devShells/default.nix | Defines the devShell (Android SDK, Chrome, JDK) and shell hooks. |
| flake.nix | Main flake wiring: inputs, overlays, Android SDK composition, packages/devShells outputs. |
| flake.lock | Pins flake inputs. |
| default.nix | Adds a non-flake Nix build expression for the Linux desktop app. |
| android/settings.gradle | Allows resolving Flutter SDK from FLUTTER_ROOT env var. |
| .gitignore | Ignores Nix build result* outputs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| local_prop_path='android/local.properties' | ||
| if [ -f "$local_prop_path" ]; then | ||
| sed -i '/^\s*flutter\./d' "$local_prop_path" | ||
| fi | ||
| cat >>"$local_prop_path" <<-EOF | ||
| flutter.sdk=$FLUTTER_ROOT | ||
| EOF |
| gradle_prop_path="$gradle_home/gradle.properties" | ||
| if [ -f "$gradle_prop_path" ]; then | ||
| args=( | ||
| -i | ||
| '/^\s*android\.aapt2FromMavenOverride\s*=/d' | ||
| "$gradle_prop_path" | ||
| ) | ||
| sed "''${args[@]}" | ||
| fi | ||
| cat >>"$gradle_prop_path" <<-EOF | ||
| android.aapt2FromMavenOverride=$ANDROID_HOME/build-tools/${androidBuildToolsVersion}/aapt2 | ||
| EOF |
There was a problem hiding this comment.
The gnused does use \s to match whitespace.
nix shell nixpkgs#gnused -c sed 's/\s*/-/g' <<<'1 2 3'
# -1-2-3-
There was a problem hiding this comment.
Can we move nix/*, *.nix, flake.lock to packaging/ subdir? It might be better to keep the project root less complicated, given that it has been already very bloaty now.
There was a problem hiding this comment.
For /nix/* we can move them into a subdir. By the way flake.nix and flake.lock must be in the same directory.
When flake.nix and flake.lock are in a subdir such as /packaging/nix/, it would require nix build github:DanXi-Dev/DanXi?dir=packaging/nix to build.
There was a problem hiding this comment.
When
flake.nixandflake.lockare in a subdir such as/packaging/nix/, it would requirenix build github:DanXi-Dev/DanXi?dir=packaging/nixto build.
I think this is acceptable. From what I recall, packaging scripts like this are typically kept in a separate repo (as is the case with Arch and Gentoo) rather than sharing the same repository as the software itself.
Since we are adopting a monorepo approach, placing it in a subdirectory might be semantically more appropriate.
(Alternatively, we could also create an independent repository, like DanXi-Dev/DanXi.nix?) Let me know what you think.
|
Please also check GitHub Copilot's suggestions. Most of them look valid to me. |
No description provided.