Bug 274411 - devel/py-urwid Update to 2.2.x breaks several python packages
Summary: devel/py-urwid Update to 2.2.x breaks several python packages
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Po-Chuan Hsieh
URL:
Keywords:
Depends on:
Blocks: 276494
  Show dependency treegraph
 
Reported: 2023-10-11 13:33 UTC by Jens Grassel
Modified: 2024-06-06 12:18 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (python)


Attachments
[patch] devel/py-urwid generates a bad version.py with scm6, require >= scm7 (735 bytes, patch)
2023-11-20 21:25 UTC, John Hein
jcfyecrayz: maintainer-approval? (python)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Grassel 2023-10-11 13:33:00 UTC
Hi,

I just noticed that the upgrade of devel/py-urwid port to version 2.x (from 1.x) breaks several python packages.

Examples:

```
% khal interactive
Traceback (most recent call last):
  File "/usr/local/bin/khal", line 33, in <module>
    sys.exit(load_entry_point('khal==0.11.2', 'console_scripts', 'khal')())
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/khal/cli.py", line 486, in interactive
    controllers.interactive(
  File "/usr/local/lib/python3.9/site-packages/khal/controllers.py", line 589, in interactive
    from . import ui
  File "/usr/local/lib/python3.9/site-packages/khal/ui/__init__.py", line 29, in <module>
    import urwid
  File "/usr/local/lib/python3.9/site-packages/urwid/__init__.py", line 72, in <module>
    from urwid.version import __version__, __version_tuple__
ImportError: cannot import name '__version__' from 'urwid.version' (/usr/local/lib/python3.9/site-packages/urwid/version.py)
```

```
% toot tui
Traceback (most recent call last):
  File "/usr/local/bin/toot", line 33, in <module>
    sys.exit(load_entry_point('toot==0.28.0', 'console_scripts', 'toot')())
  File "/usr/local/lib/python3.9/site-packages/toot/console.py", line 560, in main
    run_command(app, user, command_name, args)
  File "/usr/local/lib/python3.9/site-packages/toot/console.py", line 542, in run_command
    return fn(app, user, parsed_args)
  File "/usr/local/lib/python3.9/site-packages/toot/commands.py", line 346, in tui
    from .tui.app import TUI
  File "/usr/local/lib/python3.9/site-packages/toot/tui/__init__.py", line 1, in <module>
    from urwid.command_map import command_map
  File "/usr/local/lib/python3.9/site-packages/urwid/__init__.py", line 72, in <module>
    from urwid.version import __version__, __version_tuple__
ImportError: cannot import name '__version__' from 'urwid.version' (/usr/local/lib/python3.9/site-packages/urwid/version.py)
```

So far this seems to affect only python applications that are using a TUI interface. Tested on 13.2 with latest patches and upgrades.

Would it be sufficient to provide a patch creating a py-urwid1 port or would this mess things up even further?

Kind regards,

Jens
Comment 1 Jens Grassel 2023-10-12 08:42:28 UTC
Had time to run some tests, the last working version is py-urwid-2.1.2 (commit hash dca49dfd69fbff2c05e31310aa6c51f02dc07bd4 in ports).
Comment 2 Andreas Bilke 2023-10-17 17:53:02 UTC
I have the same situation for desktuils/py-todoman.

The issue here looks a little like bug #269686 which was also related to the switch to PEP517.
Comment 3 Andrew Morton 2023-11-07 22:12:29 UTC
Seeing this error with sysutils/s-tui.
Comment 4 John Hein 2023-11-20 17:32:46 UTC
I can get devel/py-urwid working if I build with devel/py-setuptools_scm7.  pyproject.toml claims it works with scm>=6.2, but maybe that is an upstream error.  I am still investigating that.

But I can confirm this has been broken since 2.2.1 was committed Sep 30, 2023.

@sunpoet, did this work for you?  Here it won't even import (python3.9 -c 'import urwid' fails as described in comment 0).  Same results for upstream versions 2.2.0 - 2.2.3.  The generated version.py does not have a __version__ when using scm6.

See https://github.com/urwid/urwid/issues/674
Comment 5 John Hein 2023-11-20 21:25:16 UTC
Created attachment 246453 [details]
[patch] devel/py-urwid generates a bad version.py with scm6, require >= scm7

(In reply to John Hein from comment #4)
Update to newer setuptools_scm to fix badly generated version.py.  __init__.py looks for __version__, et. al., in version.py which scm6 does not provide.  Updating to newer scm is in the works (bug 272134), but has not landed yet.
Comment 6 kaltheat 2024-03-10 23:28:15 UTC
Update of setuptools-scm seem to have landed. Can this issue go further now?
Comment 7 Andreas Bilke 2024-05-31 05:21:25 UTC
Are there some updates here? This issue keeps some applications broken for more than 6 months now.
Comment 8 Po-Chuan Hsieh freebsd_committer freebsd_triage 2024-05-31 13:50:55 UTC
I think this PR can be closed now.
Some changes (setuptools-scm 8.x, urwid 2.6.x) landed.
I cannot reproduce this problem now.

% python3.11
Python 3.11.9 (main, Apr  6 2024, 08:13:21) [Clang 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a on freebsd14
Type "help", "copyright", "credits" or "license" for more information.
>>> import urwid
>>>
Comment 9 Jens Grassel 2024-06-06 12:18:43 UTC
(In reply to Po-Chuan Hsieh from comment #8)

agreed, I'm also unable to reproduce with the current state of the packages.