meta.generated: set for script-created package sets

[ethancedwards8]

Things done

Partially addresses: #513818

CC @Sigmanificient

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[Sigmanificient]

@ethancedwards8 Hi, I've did started #513810 for this issue, but my main blocker was that i was unable to find the resource to build the package sets.

I'd like to comfirm that the generation goes well. I think it could also be an opportunity to provide some docs that truly feels missing on how to generate them from a single command

[ethancedwards8]

ah right. sorry. totally missed your PR!

[ethancedwards8]

But yes I also had a hard time finding docs to generate many of these. Which is why I only changed the ones that are generated on eval via importing json/toml/etc.

[Sigmanificient]

@ethancedwards8 I had not really advertised it either, for the above reason and that i wanted to get more feedback on the issue too 😅

[sternenseemann]

I don't think this is the right approach. This sets generated based on membership in a package set, but some packages may be created manually or generated with different methods. This is, for example, the case for haskellPackages. It seems wrong to require manually created packages to set generated = false;, but only in some contexts.

Presumably, the burden should be on the generating program to output meta.generated = true.

[ethancedwards8]

I broadly agree with your comment.

That being said, some of these functions (for example for the typst) ecosystem explicitly state they are not meant for external consumption and don't even expose themselves. This is perfectly fine I think.

I agree that if the builder is exposed to downstream consumers it should be set in the update script. vimPlugins for example.

[infinisil]

I have a fairly complete diff to do this only for actual packages that were generated. On my phone right now but I'll make a note to share it later today.

For me the motivation is NixOS/rfcs#180, because we don't want to give warnings for maintainerless leaf packages if they're generated.

[Sigmanificient]

@infinisil My motivation was also to help with scripting, but to filter out theses packages for treewide prs! (which i had noticed some editing generated files).

It sounds like you found a great usage of my silly variable :o

[Sigmanificient]

Maybe we could have it set first on check-meta? And then pinging the different team so they can handle it themselves (since they will know how to do it). We could ask to also make sure to upgrade the doc in the way

[infinisil]

Here's my diff: tweag@5034648

It's not complete nor entirely correct, but a start. There's a bunch of position fixups as well, which are often used to determine whether something lives in a generated file when there's no other way.

I'll probably be able to submit a PR for this this month along with the RFC#180 work

[infinisil]

Fwiw, unfortunately I ended up going for something more specialised for my use case: meta.requiresMaintainers. Here's the all the additions.