Draft: Deduplicate package name for hello-world template

[TakodaS]

One thing that hinders me from using uv2nix templates is the preponderance of specific pyproject naming. I think this should automatically be extracted from the pyproject's name field and used throughout, thus reducing duplication.

[TakodaS]

uv2nix/lib/workspace.nix

Lines 109 to 111 in d01fd3a

	# If workspace root is a virtual root it wasn't discovered as a member directory
	# but config should also be loaded from a virtual root
	++ optional (!(pyproject ? project)) pyproject

This line confuses me and is the reason I can't use workspace.config.name in my PR. Why do we include the pyproject config as a nix expression only if it does not have a project attribute? I don't understand the virtual roots thing. Is this in case we are loading a workspace which has multiple project definitions? Need some enlightenment before I can proceed.

[adisbladis]

This line confuses me ...

See the workspace-flat test fixture:

The root pyproject.toml doesn't have a project table, and therefore it won't be in workspaceProjects.
We still want to load supported config variables from this file however, so the presence of a project table is used a heuristic whether to forcibly include it or not.

I think this should automatically be extracted from the pyproject's name field

It's not possible to set a single name attribute given a workspace with a virtual root (like in the fixture above).
I think this case should error out when accessing the name attribute.

[TakodaS]

Would loading the config following our workspace structure work?

tool.uv.no-binary = [...];
...
workspace = {
    packages.pkg-a.project = {...};
    packages.pkg-b.project = {...};
};

[adisbladis]

I'm actually thinking that the root cause is a shortcoming in Flakes.
If Flakes used some proper templating functionality instead of just copying a bunch of files with no means of text substitution this would be a non-issue.

It's not possible to set a single name attribute given a workspace with a virtual root (like in the fixture above).

Given this I don't think we should implement any workarounds for Flake template shortcomings.