Yes, sorry my bad, I’m an idiot and shared a snippet without testing it again. outputs must be defined as a function like you do if I want to use inputs… I’m not sure it can be not a function frankly.
I assume you mean the nixpkgs.legacyPackages, right? If so, that’s totally fine and in fact the only way of doing it.
“legacy” in this case means that the packages can be nested, i.e. you can have packages like nixpkgs.legacyPackages.x86_64-linux.python3Packages.pip, as opposed to just nixpkgs.legacyPackages.x86_64-linux.pip, with the python3Packages not being allowed to be nested in the non-legacy world, so pip has to live at the top level.
Flakes technically don’t permit nesting, but because that’s how nixpkgs was historically organized an escape hatch was needed to allow nixpkgs to be provided as a flake. legacyPackages is this escape hatch.
So you can’t really choose to use it downstream, your upstream decides whether it provides legacyPackages or packages, and in the case of nixpkgs it uses legacyPackages.
I think the majority of other flakes use packages though, and there was a good reason to use packages if you ever write your own. I forgot what it was, though, nix flake check support?
As an aside, I’m not sure it will ever be possible to move away from legacyPackages for nixpkgs. The future of what full flake adoption for nixpkgs will look like is very uncertain; to enable using packages I can imagine splitting it up into multiple flakes (with e.g. a separate pythonPackages flake), but there has hardly been any serious discussion on this as far as I know.