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

Add output for poetry lock --check #5081

Merged
merged 7 commits into from
Feb 9, 2022
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions src/poetry/console/commands/lock.py
Original file line number Diff line number Diff line change
Expand Up @@ -37,11 +37,13 @@ def handle(self) -> int:
)

if self.option("check"):
return (
0
if self.poetry.locker.is_locked() and self.poetry.locker.is_fresh()
else 1
if self.poetry.locker.is_locked() and self.poetry.locker.is_fresh():
self.line("poetry.lock is up to date")
return 0
self.line(
"Error: poetry.lock is out of date. Run `poetry update` to fix it"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use <error>...</error> as in

self.line(f"<error>Error: {error}</error>")

for coloring.

Copy link
Contributor Author

@artemrys artemrys Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we wait on an opinion from triage team on this one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding <error>...</error> is safe.

Considering the wording: Since there are no replies yet, either nobody had time to think about it or has no strong opinion or is just fine with the proposal. 😉 If you want to speed up the process (and are not afraid from some more iterations of changes) we can push this PR until I will approve it. Before merging, a core member will look at the changes anyway and may (or may not) request further changes.

Thus, if you want to proceed, I propose to stick with the wording from the documentation (poetry.lock is (not) consistent with pyproject.toml) and recommend running poetry lock [--no-update]. Otherwise, you can also just wait some more days for additional opinions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose to stick with the wording from the documentation (poetry.lock is (not) consistent with pyproject.toml) and recommend running poetry lock [--no-update]

I like this one 👍

Copy link
Contributor Author

@artemrys artemrys Jan 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated messages

)
return 1

self._installer.lock(update=not self.option("no-update"))

Expand Down
4 changes: 4 additions & 0 deletions tests/console/commands/test_lock.py
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,8 @@ def test_lock_check_outdated(

tester = command_tester_factory("lock", poetry=poetry_with_outdated_lockfile)
status_code = tester.execute("--check")
expected = "Error: poetry.lock is out of date. Run `poetry update` to fix it\n"
assert tester.io.fetch_output() == expected

# exit with an error
assert status_code == 1
Expand All @@ -101,6 +103,8 @@ def test_lock_check_up_to_date(

tester = command_tester_factory("lock", poetry=poetry_with_up_to_date_lockfile)
status_code = tester.execute("--check")
expected = "poetry.lock is up to date\n"
assert tester.io.fetch_output() == expected

# exit with an error
assert status_code == 0
Expand Down