Errors not shown following clean-up of big stacks

[dimbleby]

recent work has cleaned up the big horrible stacks that poetry used to show whenever the smallest thing went wrong, which is great. But it has overshot slightly.

Example: create a project called requests, and then poetry add requests.

In an ideal world we'd get a nice clean error message saying that a project can't be a dependency of itself. But:

$ poetry add requests
Using version ^2.28.0 for requests

Updating dependencies
Resolving dependencies... (0.0s)

huh, that looks fine.

In fact poetry has hit an assertion, which you will see if you poetry add requests -vvv, and fallen over: but it has almost completely hidden this from the user.

('almost' because the exit-code is non-zero, so that's good).

This particular assertion isn't the point, the point is that when poetry does bug out it now does too good a job of disguising that.

[dimbleby]

@Bobronium I guess it must be python-poetry/cleo#132 that did this

[Bobronium]

I see your point and I agree.

Can you post the output of poetry add requests -v as well as -vv and -vvv?

From the description, my guess is that you're hitting plain assert usage without a message, which is an issue in itself and I'd say it should be replaced with something more descriptive.

To address your point: I think it really belongs to cleo. As well as my following thoughts:

It might be worth checking if exception has any args (e.g. message) and if not, fallback to printing traceback).

The more fine and "right" solution would be introducing expected exception class/set and hide traceback only for that exceptions.

[dimbleby]

$ poetry add requests -v

Using virtualenv: /home/dch/.virtualenvs/foo
Using version ^2.28.0 for requests

Updating dependencies
Resolving dependencies... (0.0s)

  AssertionError



  at ~/poetry/src/poetry/mixology/incompatibility.py:114 in __str__
      110│         )
      111│
      112│     def __str__(self) -> str:
      113│         if isinstance(self._cause, DependencyCause):
    → 114│             assert len(self._terms) == 2
      115│
      116│             depender = self._terms[0]
      117│             dependee = self._terms[1]
      118│             assert depender.is_positive()

More verbose versions are more verbose, but I think would just clog this up - indeed we have hit an assertion with no message

[mkniewallner]

It might be worth checking if exception has any args (e.g. message) and if not, fallback to printing traceback).

This seems like a good short term solution indeed, pending, as you suggest, some changes to properly raise errors with actionable error messages for the end user (as even if we do bring back tracebacks for errors without message, the user would still have to guess what the error is about).

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.