-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Documentation feedback #5605
Comments
https://docs.astral.sh/uv/concepts/python-versions/#adjusting-python-version-preferences |
We don't have a commands to modify a persistent configuration file — you can put it in a
Thanks for the feedback though! Sounds like we should link to the persistent configuration documentation here. |
A little suggestion: add the use of I habitually use --help to see what commands I can use. PS: I don't understand why it should be hidden in --help. Except for this command, the outputs of |
I'm not sure why it's hidden — I copied this from Ruff. I think it might be because it shifts the indent for the rest of the commands way to the right and dramatically reduces the space we have for concise documentation. Thanks for the feedback! Tracked in #6153 |
Maybe we can improve the |
On
This sounded to me as if By the way, I added this to my 00 00 * * * uv self update |
Minor confusion for me in https://docs.astral.sh/uv/concepts/tools/, emphasis mine:
...
For Furthermore, what does it mean "disposable" in this context? In my first reading I understood If I do |
One suggestion would be to reiterate in the CLI reference docs for Another thing is that in the tool concepts page, it directly references
In both these cases, the implicit assumption is that the user knows that |
(Thanks for the feedback everyone, I'll attempt to address all that) We should talk about defining constraints in the |
@gusutabopb let me know if #6468 is sufficient! |
Hi! I hope this is the correct place, but I would request examples for:
I ask because this does not work from my existing pyproject.toml:
I add auth to the config by running:
Finding the equivalent of that last line for I'm similarly interested in jfrog examples, but this is the one I can provide the most specific details on. |
The FastAPI guide needs to be updated to reflect the changes introduced to the default behavior of |
|
I'm not sure why there's a python-version file if this information is also in the |
The documentation about running scripts using the inline metadata (link) doesn't mention support for specifying the dependency sources via the # /// script
# requires-python = ">=3.12"
# dependencies = [
# "requests",
# ]
# [tool.uv.sources]
# requests = { git = "https://github.com/psf/requests.git", tag = "v2.32.2" }
# ///
import requests
print(requests.__version__) # 2.32.2 (2.32.3 is the latest) I think the documentation can be explicit about officially supporting (or not supporting) it. |
@shunichironomura thanks! I think we need to create a separate "Scripts" concept page because that's way too advanced for the "guide" documentation. |
Would be nice to have information on whether virtual workspaces (no |
You might be looking for this: https://docs.astral.sh/uv/concepts/projects/#applications |
That is still an application that has its own python code from what I can tell. The Cargo virtual workspaces just combine related packages together, where there isn't necessarily one "main" binary. Taking from the workspace example in uv docs,
imagine And just to be clear, I'm not asking this feature to be implemented, only clarification on whether or not it is supported because the documentation page explicitly refers to Cargo. |
I have a couple questions about the lockfile after reading the docs on it. Is the The reason I'm looking for a schema / specification is that I would like to be able to parse My other question is whether you expect the |
@scimas Virtual projects were removed in #6720 (from the docs at least - cannot quickly find other pointers) |
@scimas -- Yeah that layout is fully supported. You can create a @astrojuanlu -- We removed most mentions of "virtual" since it wasn't a familiar concept, but the idea of a project that just lists members and dependencies is still supported. |
@eliasdabbas I like the Python version of the link checker. Definitely useful. Would be interested to see how it compares to Rust based https://lychee.cli.rs/ |
@abitrolly I'm not familiar with Lychee, but I just took a look. Based on what I saw so far: Pros: It can check links in a tree locally, supports .md .rst and HTML. This makes it great for pre-commit checks/hooks. Cons: It doesn't support recursive crawling of websites, which includes discovering links, following them, redirects, etc. Python pros: Supports recursive crawling with customizable rules, and can be as fast as you want it to be. Python cons: Does not support .md or .rst. So if you want the actual live website the advertools/Python solution seems better, if you want to check .md or .rst files, it seems Lychee is the good choice. Again I'm not that familiar with it, so take what I said with a grain of salt. |
When I build and run the container from the Docker example as-is, I get this error:
|
@carrollpaul I tested that just now and cannot reproduce. Please open an issue with a reproduction. |
The docs for deploying a zip archive for AWS lambda ( https://docs.astral.sh/uv/guides/integration/aws-lambda/#deploying-a-zip-archive ) includes the usage of |
It exists, it's just not visible on the CLI. It's analogous to: https://docs.astral.sh/uv/configuration/environment/#uv_no_installer_metadata. |
I have switched to uv for most of my projects and am wondering if there is an easy way to create a snapshot of the environment. I need to experiment with upgrades and dependencies, and if things go wrong, revert to the original snapshot. In the past, I used |
All information is contained in If things go wrong, replace these files with the backed up files and run |
Some misc docs feedback before I forget... Locking and syncing concepts pageIf I search the docs for "sync", the top result is the "Locking and Syncing" concepts page: The page has "syncing" in the title and "sync" in the URL, but the page content itself really only seems to be about locking rather than syncing, which was surprising - since I was hoping to find more about
|
Perhaps it would be a good idea to point this out: https://docs.astral.sh/uv/reference/settings/#find-links on this page: https://docs.astral.sh/uv/configuration/indexes ? |
That’s awesome feedback, thanks @edmorley. |
I'm having some difficulty with the Build Systems as a new Right now, the docs are explaining what a build system does for you and mentions that you can choose one with a parameter to
And because I'm still in poetry/uv limbo, I have this still defined, but
|
uv supports all build backends because we are a standards-complaint build frontend. The We don't have an opinionated default. We use hatchling right now, because we think it's a reasonable option. We're working on our own build backend, which will be used by default eventually. If you don't define a build backend, we won't install your project itself into the environment (but will still install its dependencies). I believe these things are outlined in https://docs.astral.sh/uv/concepts/projects/init/#creating-projects (in addition to the build system document you referenced). We could clarify the role of build frontends in the document you linked though. |
I think digestibility of the sidebar could be made better with some styling changes. Currently, there isn't enough contrast between headings in the nav and the nav items. They are almost the same size, use the same font, have the same spacing, same color, etc. To me at least, that makes them run together and feels a bit overwhelming. Makes it harder to visually scan for what I'm looking for. Consider mise's docs which have a similar volume of content in the sidebar nav but, at least to me, don't feel nearly as "crowded" or overwhelming: |
The section Resolution - Required environments doesn't explain the syntax and certainly not the semantics of this environment marker language. From uv's docs on functionally similar features, I found a reference to PEP 508. That, however, is marked as deprecated when visited, and superseded by Dependency specifiers. I propose that uv's documents this language in a single place, that references Dependency specifiers and just that. |
@cmsirbu - I'm terrible at design. I usually try to find a template that has this done "right" by someone who knows aesthetics better than me. :) But, here are some thoughts:
HTH. :) |
I guess I don't really see that as a clear step forward, especially since it clobbers the active link styling. |
It's also worth noting that ~half of the Mise nav is below the page fold. It's an explicit goal to minimize that here. I think the proper fix for this is probably to add horizontal sections, which I've explored but will requires some serious reorganization and isn't a priority at the moment. |
@rsyring There's a limit to what one can do in a browser "inspect" window with average css skills, I know when to stop 🙂
It's more of a take from it what might be useful than "do this". More to the point, I initially only wanted to post the padding option, which might be a good solution for adding visual separation if you don't want to increase the vertical spacing too much (to keep as much as possible on the screen). Is it too much indentation? 🤷🏻 It's python we're talking about... |
I'm not sure concern about what's above the fold is that helpful in technical documentation, especially navigation when it's intuitive, especially for technical users, to want to scan through something to easily get the "lay of the land." That's usually reserved for a different type of content and user interaction. The audience who reads these docs is technical and giving them the ability to easily scan what the docs offer is a more important concern. I've never felt any hesitation when reviewing mise's docs b/c there is a lot of navigation. On the contrary, I've always found it helpful b/c it makes me aware of what's the there but easily allows me to move past it when I'm focused on a specific task. To move this out of the realm of opinion, this might be a helpful reference: https://www.nngroup.com/articles/eyetracking-tasks-efficient-scanning/#toc-design-for-efficient-scanning-7
I'd encourage you to avoid horizontal navigation b/c it takes the scanning from a single dimension (vertical) to two dimensions (vertical + horizontal) and perhaps three dimensions if you have to click into a page in a section before you see it's horizontal navigation change. Makes getting the lay of the land much more difficult. I think your current nav, two layers on left plus page TOC on the right once you are on a page is one of the best docs layout there is. Just need to visually de-clutter the left nav.
IMO, it is a clear step forward. Maybe not the last step, but the change in indentation and padding is a significant improvement.
Nope. Just right IMO. Don't forgot to preview the mobile/responsive versions. Are all the font sizes the same? I think a slightly smaller font at each level will enhance visual distinction. |
Should we move the specifics of the nav changes to a different issue to avoid overwhelming this one? |
Let's chat in #11757 |
This comment has been minimized.
This comment has been minimized.
(uv 0.6.5) |
|
This is a tracking issue for feedback on the new documentation at https://docs.astral.sh/uv/
The text was updated successfully, but these errors were encountered: