uv init: Project layouts, defaults and terminology

Thank you for working on this wonderful tool. I'd like to suggest several changes to `uv init` arguments and defaults, with the following goals: - Use consistent and established terminology - Options to support common usage patterns, so seasoned Python developers can have things their way - Defaults which guide Python newcomers towards best practices, hint at available features Much of this revolves around separating the concept of project directory structure ("layout" in Python) from project purpose and contents ("library", "application", etc), as well as disambiguating the overloaded term "package". Currently these terms are conflated and inconsistent in `uv`. Apologies in advance for the massive wall of text. ## Current behavior "Application" (default): ```sh $ uv init [--app] project-name $ tree project-name/ project-name/ ├── hello.py ├── pyproject.toml # only [project] (builds don't work due to misnamed hello.py) └── README.md ``` "Library": ```sh $ uv init --lib project-name project-name/ ├── pyproject.toml # [project], [build-system] ├── README.md └── src └── project_name ├── __init__.py # contains "hello" code └── py.typed ``` "Application Package": ```sh $ uv init [--app] --package project-name # --app appears to do nothing here, in spite of docs suggesting it project-name/ ├── pyproject.toml # [project], [project.scripts], [build-system] ├── README.md └── src └── project_name └── __init__.py # contains "hello" code ```

Posted by MikeHart85 on Oct 14, 2024, 5:19 PM

Tags

• support (SaaS)

Related issues

• As I replied in another comment[1], it's their software, their choice.
• [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
• > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
• Feature request: support multiple named accounts per app/connector
• Support standalone Windows installer (`codex-setup.exe`)
• [feature]: Move OIDC back to self-hosted OSS(Plane Free)