feat: output write-* to packages also

[theutz]

This is useful since the apps output doesn't give you easy access to a derivation, as far as I can tell, so it's harder to include in something like devshells

[vic]

I believe we should have only one.

#92

@Adda0, any take on this ?

[theutz]

I generally agree there probably should only be one. It’s not the end of the world if this doesn’t get accepted. I just didn’t know if there was a distinct advantage to using apps instead of packages.

…

On Mon, Apr 13, 2026, at 17:51, Victor Borja wrote: *vic* left a comment (denful/flake-file#98) <#98 (comment)> I believe we should have only one. #92 <#92> @Adda0 <https://github.com/Adda0>, any take on this ? — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYU7B6GIT6TK5CAFDUCYD4VT5IPAVCNFSM6AAAAACXXJQABWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZXGMYTQOBRG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[vic]

I mean, we gain almost nothing for having them at apps we moved them because I had no opinion on not doing so, I've always by instict use packages. From previous PR what I understand is, apps is for things not intended to be consumed by downstream flakes.

How is it more difficult to add them at devshells when exposed via flake.apps ? Maybe we can document about config.flake-file.apps and recommend people to use those ?

Or simply move again to packages, I'm not against that, I just prefer not having both.

[theutz]

Great question! Per the devshells docs, you can define a command by adding an entry with the shape { package = <p>; } where p is "null or (package or string convertible to it)".

In most instances, this is just a string that can be getAttrFromPath'd from pkgs. But in our case, since they come from our flake, they have to be in the form of a package / derivation. The output from apps is an attrset that exposes .program, which resolves to a stringified store path for the main exe for the app. Unfortunately, devshell can't use that string to understand it's a package, and so it fails.

I'll give you a side-by-side for more insight:

{ config, ... }:
{ devshell = {
  commands = [
    # with apps
    { name = "write-flake"; command = config.apps.write-file.program; }
    # with packages
    { package = config.packages.write-file; }
  ];
}

So, yeah, you can see it's not really a big deal either way! But the files tool for flake parts uses packages, so it would be in keeping with another existing paradigm if we used packages, too.

I'm torn. I'll leave the final decision to the wisdom of the group!

[theutz]

I guess one other potential benefit for package is that devshell reads the meta.description and would use that to auto-generate help text in it's message of the day menu. We don't currently add any meta.description, so it's moot currently. But we could and it would!

[vic]

Yep, so this issue actually exposing a difference (definitive advantage) about using packages vs apps, is a good thing. Like I said, previously I had no opinion on this, but thanks for mentioning things like access to description,meta.mainProgram and easy of use for devshells, that definitely help in making a better decision.

Having a reason, we can now know why to use packages vs apps.

I mean, we gain nothing from apps, but gain more from using packages. So let's use packages.

[theutz]

Ok! I went ahead and added a meta.description property to each of the writers, too, that I adapted from the docs.

[theutz]

I'll take a look at these failing tests.

[theutz]

I'll take a look at these failing tests.

It was some kind of issue with the nothing-but-nix action. A 504 with something it was trying to curl. But it looks like it's fixed now.

[vic]

FFTM (Feel free to merge -- just invented that)

[theutz]

FFTM (Feel free to merge -- just invented that)

ILT (I like that)