Conversation
| .map(|fs| fs.install_mirrors.clone()) | ||
| .unwrap_or_default(); | ||
|
|
||
| let no_description = no_description || (bare && description.is_none()); |
There was a problem hiding this comment.
This is a little dubious (implementation-wise), but I didn't want to get sucked into refactoring the description handling.
|
I'll want to add some prose documentation too, but let's see where this goes first. |
|
Also open to another name? I'm not sure what though. Some people in the linked issues think this should be the default and everything else should be opt-in. I'm a little hesitant about that. |
I do think this flag/mode is a good baseline for other flags to opt back into features. ( |
Gankra
left a comment
Gankra
left a comment
There was a problem hiding this comment.
Don't have a strong opinion of the name but the impl seems reasonable.
|
|
||
| /// Set the project description. | ||
| #[arg(long, conflicts_with = "script")] | ||
| #[arg(long, conflicts_with = "script", overrides_with = "no_description")] |
| }; | ||
|
|
||
| // Initialize the version control system. | ||
| init_vcs(path, vcs)?; |
There was a problem hiding this comment.
Wait hold on shouldn't these be wrapped too (in a few places?)
There was a problem hiding this comment.
A little questionable, but makes the --vcs git behavior easier.
|
|
||
| /// Only create a `pyproject.toml`. | ||
| /// | ||
| /// Disables creating extra files like `README.md`, the `src/` tree, `.python-version` files, |
There was a problem hiding this comment.
I wonder whether --bare should still create a .python-version file (if one doesn't already exist), given how integral it is to the deterministic operation of uv? It seems like most of the feedback about unwanted files/content were about the .py files and directory nesting, rather than the .python-version file - so people might be fine with it left in?
There was a problem hiding this comment.
People are sort of constantly complaining about the .python-version file actually :/
It don't think it's required for reasonably deterministic action if you have a requires-python in your project. You may be on a different version than someone else, but the lockfile will be consistent.
There was a problem hiding this comment.
People are sort of constantly complaining about the
.python-versionfile actually :/
Yeah I've seen quite a few comments, but from what I remember they were in other issues (not about uv init defaults), and generally were about lack of understanding why the seemingly duplicate concepts were needed.
I think longer term perhaps campaigning for an additional Python version field to be added to the pyproject.toml spec would resolve the "why do I need another file" concerns, but for now I think having a pinned Python version via a .python-version file really is still important. Otherwise the day after uv adds support for eg Python 3.14, some developers on a project will end up using Python 3.14 (with lack of wheels), whereas others on their team (who may not have updated uv yet) could still be using Python 3.13 etc - leading to only some people seeing build failures (due to building from source), CI failures, lack of dev-prod parity etc.
It's very likely I'm going to make a missing .python-version file a hard error when deploying a uv app on Heroku for example.
There was a problem hiding this comment.
Yeah, I think your take is fair.
My primary concern is that it doesn't make much sense to teach --bare if it does more than just create a pyproject.toml with standards-compliant fields. I'd rather add opt-in support via --pin-python and suggest using it.
It seems feasible that there'd be interest in a standard for a Python version pin in the pyproject.toml; especially now that there are dependency groups that do not require [project] metadata. I'm not excited about trying to pitch it though :D I agree this is the obvious long-term solution over a non-standard .python-version file.
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.5.27` -> `0.5.29` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.5.29`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0529) [Compare Source](astral-sh/uv@0.5.28...0.5.29) ##### Enhancements - Add `--bare` option to `uv init` ([#​11192](astral-sh/uv#11192)) - Add support for respecting `VIRTUAL_ENV` in project commands via `--active` ([#​11189](astral-sh/uv#11189)) - Allow the project `VIRTUAL_ENV` warning to be silenced with `--no-active` ([#​11251](astral-sh/uv#11251)) ##### Python The managed Python distributions have been updated, including: - CPython 3.12.9 - CPython 3.13.2 - pkg-config files are now relocatable See the [`python-build-standalone` release notes](https://github.com/astral-sh/python-build-standalone/releases/tag/20250205) for more details. ##### Bug fixes - Always use base Python discovery logic for cached environments ([#​11254](astral-sh/uv#11254)) - Use a flock to avoid concurrent initialization of project environments ([#​11259](astral-sh/uv#11259)) - Fix handling of `--all-groups` and `--no-default-groups` flags ([#​11224](astral-sh/uv#11224)) ##### Documentation - Minor touchups to the Docker provenance docs ([#​11252](astral-sh/uv#11252)) - Move content from the `mkdocs.public.yml` into the template ([#​11246](astral-sh/uv#11246)) ### [`v0.5.28`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0528) [Compare Source](astral-sh/uv@0.5.27...0.5.28) ##### Bug fixes - Allow discovering virtual environments from the first interpreter found on the `PATH` ([#​11218](astral-sh/uv#11218)) - Clear ephemeral overlays when running tools ([#​11141](astral-sh/uv#11141)) - Disable SSL in Git commands for `--allow-insecure-host` ([#​11210](astral-sh/uv#11210)) - Fix hardlinks in tar unpacking ([#​11221](astral-sh/uv#11221)) - Set base executable when returning virtual environment ([#​11209](astral-sh/uv#11209)) - Use base Python for cached environments ([#​11208](astral-sh/uv#11208)) ##### Documentation - Add documentation on verifying Docker image attestations ([#​11140](astral-sh/uv#11140)) - Add `last updated` to documentation ([#​11164](astral-sh/uv#11164)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNTguMSIsInVwZGF0ZWRJblZlciI6IjM5LjE1OC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
3 participants
People are looking for a less opinionated version of
uv init. The goal here is to create apyproject.tomland nothing else. With the--libor--packageflags, we'll still configure a build backend but we won't create the source tree. This disables things like the defaultdescription, author behavior, and VCS.See
uv initoptions more user-friendly #7181main.pyin existing projects #6750