ldtk: init at 1.1.3 #178896
ldtk: init at 1.1.3 #178896
Conversation
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
833fbb1 to
d8877db
Compare
|
|
||
| nativeBuildInputs = [ unzip ]; | ||
|
|
||
| buildInputs = [ appimage-run ]; |
There was a problem hiding this comment.
Why use a pre-built AppImage at all? Wouldn't it be better to compile the package from the source?
There was a problem hiding this comment.
There is no a priori prohibition to precompiled packages in NixOS.
Also, it is not always easy to build a package from sources - look at the guy trying to compile KoReader:
I would only suggest to rename it to ldtk-appimage in order to differentiate future source-based build expressions.
There was a problem hiding this comment.
There is no a priori prohibition to precompiled packages in NixOS.
We always prefer building from source if it is easily possible.
I would only suggest to rename it to
ldtk-appimagein order to differentiate future source-based build expressions.
No, we should set meta data to reflect that it isn't build from source.
There was a problem hiding this comment.
We always prefer building from source if it is easily possible.
Nonetheless it is not a veto or avoidance of precompiled based packaging "at all costs".
No, we should set meta data to reflect that it isn't build from source.
Sometimes both source-based and precompiled packages are used in Nixpkgs. Obviously they can't have the same exact name in all-packages.nix.
There was a problem hiding this comment.
Nonetheless it is not a veto or avoidance of precompiled based packaging "at all costs".
If the package is using a standard build system (make, autotools, cmake, etc), has good nixpkgs support (eg not maven, gradle, javascript) and is not proprietary, then fetching a precompiled binary is not acceptable. Some packages are really cumbersome to build where we can make exceptions on a case by case basis.
Sometimes both source-based and precompiled packages are used in Nixpkgs. Obviously they can't have the same exact name in
all-packages.nix.
Yes but that is not the case here. All packages that only have one variant don't get a suffix. Also we should only maintain two versions if the compiled version has major drawbacks.
There was a problem hiding this comment.
I think we can make an exception there because building from source is not easy and upstream has seemingly no good support for linking against system libraries. Going the proposed way there leaves us with a lot of code to maintain which is not worth it.
There was a problem hiding this comment.
If the package is using a standard build system (make, autotools, cmake, etc), has good nixpkgs support (eg not maven, gradle, javascript) and is not proprietary, then fetching a precompiled binary is not acceptable. Some packages are really cumbersome to build where we can make exceptions on a case by case basis.
That being said, it requires Haxe, Electron and NPM. Hard but doable.
There was a problem hiding this comment.
I'd rather have this built from source, too. I don't think I can accomplish it with my current abilities & time, though.
|
|
||
| nativeBuildInputs = [ unzip ]; | ||
|
|
||
| buildInputs = [ appimage-run ]; |
There was a problem hiding this comment.
There is no a priori prohibition to precompiled packages in NixOS.
Also, it is not always easy to build a package from sources - look at the guy trying to compile KoReader:
I would only suggest to rename it to ldtk-appimage in order to differentiate future source-based build expressions.
|
Thank you for this! :) |
|
Successfully created backport PR #179591 for |
Description of changes
Adds LDtk: A modern 2D level editor from the creator of Dead Cells, with a strong focus on user-friendliness.
Closes #168277
The AppImage is distributed within a zip file and I haven't found a way to use that with
appimageTools.wrapType2, thus I'm using a wrapper which runsappimage-runinstead.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes