Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Deduplicate package name for hello-world template #138

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

TakodaS
Copy link

@TakodaS TakodaS commented Mar 4, 2025

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 TakodaS marked this pull request as draft March 4, 2025 17:36
@TakodaS
Copy link
Author

TakodaS commented Mar 4, 2025

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
Copy link
Member

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
Copy link
Author

TakodaS commented Mar 5, 2025

Would loading the config following our workspace structure work?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants