Thanks for this Pull Request. However, I am not quite sure about its use.

What should switching the config file creation from preBuild to postPatch change? Both phases are after the patch action. Afaik, slstatus does nothing in the configurePhase.

Could you please elaborate and perhaps give an example which worked after those changes? Thanks.

according to st, you can look here https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/st/default.nix, which is able to patch, then i guess it will work on slstatus, prebuild do skipping config phase while postpatch work. That's the example.

while prebuild need more configuration i guess? postpatch just patch the "inherit" patch given so the order here matter.

How is it going @oxzi ?

Please excuse the delay on my side. This PR slipped under my radar.

postpatch just patch the "inherit" patch given so the order here matter.

I'm not sure if I understood you correctly, but botch patches and postPatch are part of the patch phase. These two are processed almost independently of each other. Thus, at first all patches will be applied. Afterwards the postPatch hook will be executed. Their only connection is the order: patches first, postPatch second.

However, the current state is to use preBuild instead of postPatch to create the configuration file. Between the patch and build phase is the configuration phase, as the documentation says. This phase handles the execution of ./configure or the like.

Nevertheless this configuration phase does nothing for slstatus. There is no configure file in the source and afaik suckless' philosophy considers this as bloat. If you look at a recent build, there is "no configure script, doing nothing" for the configure phase. This leaves us with patches (patch phase), nothing to do (configure phase), preBuild (build phase).

Thus, the execution order is the same: patches first, postPatch/preBuild second; and nothing in between. I do not see the change your Pull Request tries to introduce. Perhaps I am missing something, sorry. Could you please show a real example (one or two patches) which does not work currently, but will work after your changes are introduced.

Dear @oxzi, as I said before, according to st which you can look here and dwm here both do use postpatch and was able to patch if i give an input diff there, in nix.config.st.patches = [ diff here ] or nix.config.dwm.patches = [ diff here ], based on both apps i'll do the same here to slstatus and hoped it able to patch, and of course those are not using the ./configure thingy cause yes you mention the philosopy, honestly i still don't know how to like 'sandboxing' this thing, if you were know how, just let me know.

based on both apps i'll do the same here to slstatus and hoped it able to patch

As I tried to explain to you in previous post, your commit introduces no difference in the current slstatus derivation. Furthermore, it seems like you have not tested your proposal whatsoever.

according to st which you can look here and dwm here both do use postpatch and was able to patch if i give an input diff there, in nix.config.st.patches = [ diff here ] or nix.config.dwm.patches = [ diff here ]

Like always, the devil is in the detail. Let's have a look at the top level package collection where the package derivations are called.

Both st and dwm override patches with config.{st,dwm}.patches. Such an entry is missing for slstatus, which only supports config.slstatus.conf. Thus, I would try to introduces patches = config.slstatus.patches or []; in the all-packages.nix file.

Ahhh so, so, the top-level thingy, hope you introduced it to slstatus soon, can't wait for it, you can close this pull req then, anyway, you haven't mention how to test the package, still i don't know, perhaps if i know, i'll become the maintainer right then haha.

Yes sorry, some things are not too obvious in Nix at first sight.

Why don't you want to add this change? Perhaps in this very Pull Request?

I want, but as I said, I didn't know how to test it, perhaps it will end up like this haha.

Don't be afraid of failure, just try it out. A good first pointer would be the quick start guide.

In a nutshell, you have to clone the nixpkgs repository locally and modify it within the git branch you want to submit as a Pull Request. After introducing your changes, you can build the modified slstatus package from within the cloned nixpkgs directory via nix-build -A slstatus. The results symlink should point to the created slstatus package with a bin sub-directory containing the executable.

@oxzi ok, at least I managed to do it, checkout my new pull request Alv, #102559