Unified packaging process

[Ballasi]

Hey!

It seems to me that xdg-ninja is packaged quite poorly in some cases, like putting a symlink to the programs/ directory directly in the bin/ folder of the system or modifying the script in place to patch the location of the programs/ directory.

This mostly is a consequence of the way the script currently fetches the programs/ directory:

xdg-ninja/xdg-ninja.sh

Line 221 in 4644d40

$(jq 'inputs as $input | $input.files[] as $file | $input.name, $file.path, $file.movable, $file.help' "$(realpath "$0" | xargs dirname)"/programs/* | sed -e 's/^"//' -e 's/"$//')

i.e., directly in the current working directory of the xdg-ninja script.

This works fine when working within the git repository but does poorly when trying to package the program as there needs to implement hacks to get this working.

On a useless note, I wouldn't have hacked it this way on my side, I would've just packaged xdg-ninja in the same directory as programs in, for instance, /usr/share/xdg-ninja/ and would create a wrapper script that would call /usr/share/xdg-ninja/xdg-ninja.sh.

I am unsure whether or not this is a goal of your program to be packaged, but if so, I have implemented an simple way to unify the packaging process.

---

My main goal, when modifying the script, was to get it backwards compatible with how it was previously used, i.e. when working in the git repository, it does fetch the current programs/ dir rather than somewhere else.

So I have just set the script to check in the current working directory and replace ending instances of /bin to /share/xdg-ninja (where the programs/ dir is located when packaged).

If all cases it fails, the XN_PROGRAMS_DIR can be used to override that value. I have preferred to use this instead of a --programs-dir= argument as this isn't something meant for common usage either.

I've also allowed people to override where the script is supposed to be located with the PREFIX variable in the Makefile, I believe package managers should package apps to /usr instead of /usr/local so at least it can be changed. This make variable and DESTDIR and both common naming standards.

[b3nj5m1n]

Hi! Thank you very much for this, it seems like a much-needed change.

The only concern I have is with the Install section in the README. I'm not sure that it makes sense to present this to users as the best/only option.

There is another big issue with packaging, I think perhaps I should finally think of something to fix that, update the packages, (I'm aware of arch, homebrew and nix) then write a proper installation section which recommends installing through a package manager first. The README needs a bit of an overhaul anyway tbh.

If you're okay with it, I'd say remove the Install section for now.

And again, thanks for putting time into this!

---

^{Btw, this breaks the nix flake, I tried to update it but it seems I don't have write permissions for this PR, I'll just leave the patch here, if you want to apply it that'd be great, otherwise I'll do it after merging.}

From 640977d61030c576da3b47edfa09fd651b75a6ee Mon Sep 17 00:00:00 2001
From: b3nj5m1n <[email protected]>
Date: Sun, 23 Apr 2023 08:00:13 +0200
Subject: [PATCH] Update flake

---
 flake.nix | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/flake.nix b/flake.nix
index 91adf01..8f3a5bf 100644
--- a/flake.nix
+++ b/flake.nix
@@ -26,7 +26,25 @@
       in rec {
         packages = flake-utils.lib.flattenTree {
           # The shell script and configurations, uses derivation from offical nixpkgs
-          xdg-ninja = pkgs.xdg-ninja;
+          xdg-ninja = pkgs.stdenv.mkDerivation rec {
+            pname = "xdg-ninja";
+            version = "0.1.0";
+
+            src = ./.;
+
+            nativeBuildInputs = with pkgs; [ makeWrapper ];
+
+            installPhase = ''
+              runHook preInstall
+
+              DESTDIR="$out" PREFIX="/usr" make install
+
+              wrapProgram "$out/usr/bin/xdg-ninja" \
+                --prefix PATH : "${pkgs.lib.makeBinPath [ pkgs.glow pkgs.jq ]}"
+
+              runHook postInstall
+            '';
+          };
           # Pre-built binary of xdgnj tool downloaded from github
           xdgnj-bin = pkgs.stdenvNoCC.mkDerivation {
             name = "xdgnj-bin";
@@ -45,7 +63,7 @@
         };
         defaultPackage = packages.xdg-ninja;
         apps = {
-          xdg-ninja = flake-utils.lib.mkApp { drv = packages.xdg-ninja; };
+          xdg-ninja = flake-utils.lib.mkApp { drv = packages.xdg-ninja; exePath = "/usr/bin/xdg-ninja"; };
           xdgnj-bin = flake-utils.lib.mkApp { drv = packages.xdgnj-bin; exePath = "/bin/xdgnj"; };
         };
         defaultApp = apps.xdg-ninja;
-- 
2.39.2

[Ballasi]

I haven't taken the time to take a look at nix as I am unfamiliar with this distro, so that's a good thing you were able to test that on your side. I have tested this on Ubuntu and Arch.

I have added your patch on my branch and removed the Install section of the README as discussed.

[b3nj5m1n]

Great, thank you very much again!

[Ballasi]

No problem, I can see that the AUR package for xdg-ninja-git has already been updated too!

From there, I can only recommend you to do a new GitHub release to push an update to the xdg-ninja AUR package which relies on tags/releases rather than the git repository version itself.

[b3nj5m1n]

I can only recommend you to do a new GitHub release

Yeah, I'm still thinking about how to handle releases, I could either use them exclusively for xdg-ninja, (the script & new json files) or have a prefix for xdg-ninja/xdgnj to distinguish between the two.

I can see that the AUR package for xdg-ninja-git has already been updated too!

Wow that was quick!