Idea: packages' input for perSystem which is equivalent to self'.packages

[cor]

In projects that use flake-parts, very often there are references to self'.packages. It might be nice to define packages' as one of the possible inputs for the perSystem function, which is defined as self'.packages

[shanesveller]

Do you see this as offering any new possibilities for things you couldn't express without it, or is it purely for convenience/concision?

[cor]

Do you see this as offering any new possibilities for things you couldn't express without it, or is it purely for convenience/concision?

It is purely for convenience/concision

[roberth]

This will trade a bit of learning for quite a bit of convenience.
Possible downsides:

• fewer people may learn to use config
• this adds yet another way to access the same thing

I think the name could be packages, to mirror the local option. The ' is only necessary for naming things that come from outside of perSystem.
Whether it should be taken from self'.packages or config.packages, I'm not quite sure

self'.packages

• if (if) Nix is to implement caching at the flake boundary between flakes, instead of at the more-or-less CLI level, this will be faster
• may contain extra packages if flake-parts is used in a recursiveUpdate-like expression with something else. I'd recommend people to use the flake option for this instead.

config.packages

• will never become strict in the attrset values, whereas we may implement the removal of empty attributes between the module system and the flake interface. In other words: lazier, so fewer infinite recursions 🎉

[cor]

I think the name could be packages, to mirror the local option.

Agreed

• fewer people may learn to use config

I in fact didn't know about how to use config. Can't find info on how it works on flake.parts, are there any docs on how to use this? We're currently using self'.packages everywhere. Didn't run into any infinite recursions yet though

[roberth]

any docs

Not much beyond "config, options, lib, ...: standard module system parameters."
This assumes experience with the module system, which is not something I can assume anymore as the project grows. There's no module system manual, sadly.
I will add more learning style docs (but might take a while).

Didn't run into any infinite recursions yet though

Great! I've held of the attribute filtering changes that would cause them. I'll keep prioritizing robustness over aesthetics.

[dhess]

On a related note, I was surprised to see that pkgs passed to perSystem doesn't include self.overlays, per my testing and this comment here: #50 (comment)

I suppose I can see the argument that it's not what you always want, or that it might be surprising, but it would be helpful if there were an additional pkgs argument passed to perSystem which included the local overlays.