Codecov Report

❌ Patch coverage is 95.83333% with 15 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

Merging this PR will not alter performance

✅ 2 untouched benchmarks

_{Comparing copilot/add-support-for-poetry-backend (a271da7) with main (cb84b07)}

@copilot there is a lot of test coverage missing. please aim for 100% code coverage on the new code.

Please make sure to add poetry as a test dependency so that it can be used in the test suite.

@copilot there is a lot of test coverage missing. please aim for 100% code coverage on the new code.

Please make sure to add poetry as a test dependency so that it can be used in th...

Added poetry as a test dependency and wrote comprehensive tests achieving 100% code coverage on all new poetry backend modules (available.py, call.py, deps.py, detect.py, errors.py, init.py). Tests cover all branches including error handling, verbose mode, subprocess failures, FileNotFoundError, and API compatibility parameters. See commit e6e5ec6.

@copilot try testing the user experience again - this time be more rigorous to stay on the happy path

@copilot try testing the user experience again - this time be more rigorous to stay on the happy path

Applied rigorous user testing following the usethis-cli-user-test skill procedure from fresh temp directories. Discovered and fixed a critical issue in b915d51:

Bug found: usethis init --backend=poetry failed at poetry add deptry because Poetry's poetry init generates unbounded requires-python = ">=3.10", which conflicts with its own resolver when packages depend on Python <4.0.

Fix: opinionated_poetry_init() and ensure_pyproject_toml_via_poetry() now pass --python ">=3.X,<4.0" to poetry init, producing a bounded constraint that the resolver can handle.

All happy-path commands verified in fresh projects:

• usethis init --backend=poetry — all tools added successfully (exit 0)
• usethis tool ruff --remove --backend=poetry — removes deps and config
• usethis tool ruff --backend=poetry — re-adds with correct poetry run instructions
• usethis tool pre-commit --backend=poetry — adds hooks, runs install
• usethis tool pre-commit --remove --backend=poetry — uninstalls hooks
• usethis tool pre-commit --remove --frozen --backend=poetry — shows 3-step add/uninstall/remove instructions
• usethis tool ty --frozen --backend=poetry — frozen mode prints install instruction
• usethis show backend — auto-detects "poetry"
• usethis show name / usethis list — work correctly

@copilot I noticed during my testing that the usethis init --backend=poetry command will not create a src directory with the package name automatically. I would expect the same kind of directory to be generated automatically as what gets generated by uv

E.g. for a package named fawgaw that we get

src / fawgaw / __init__.py with the body

def hello() -> str:
    return "Hello from fawgaw!"

And src / fawgaw / py.typed (single blank line) as well. Compare with usethis init --backend=uv for reference.

@copilot I noticed during my testing that the usethis init --backend=poetry command will not create a src directory with the package name automatically. I would expect the same kind of directory t...

Fixed in 95ce142. project_init() now calls _create_project_structure() after opinionated_poetry_init(), which creates README.md, src/<pkg>/__init__.py (with the hello function), and src/<pkg>/py.typed — matching the same structure that uv init --lib generates. The duplicated logic from the none backend was extracted into the shared _create_project_structure() helper.

Verified via user testing in a fresh temp dir: usethis init --backend=poetry now produces the full project structure.

@copilot we've got a big gap at the moment - we're not supporting poetry's custom dependency specification standard

Read about it here:...

Fixed in 95247f5. Added support for reading Poetry's custom dependency specification from [tool.poetry.dependencies] and [tool.poetry.group.*.dependencies] sections.

When the poetry backend is active, get_project_deps() and get_dep_groups() now merge results from both standard (PEP 621/PEP 735) and Poetry-format sections. The parser handles:

• Simple version strings: requests = "^2.28"
• Dict specs with extras: requests = {version = "^2.28", extras = ["security"]}
• Git/path/URL deps (name extracted from key)
• python key excluded automatically

This means is_dep_in_any_group() and all dependency detection now works correctly for legacy Poetry projects.

@copilot also add support for detecting poetry usage via poetry.toml's presence

see

https://python-poetry.org/docs/main/configuration#installerbuild-config-settingspackage-name

@copilot also add support for detecting poetry usage via poetry.toml's presence

see
...

Detection via poetry.toml was already implemented in is_poetry_used() (along with poetry.lock and [tool.poetry] in pyproject.toml), with a dedicated test in test_detect.py::TestIsPoetryUsed::test_poetry_toml. Updated the docs/about/backends.md documentation in 5e4286d to explicitly list all three detection methods.