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.

Sign up for GitHub

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

Jump to bottom

Commands not found on Debian Buster ('init' is not a stestr command.) #336

Closed
ianw opened this issue Oct 18, 2022 · 4 comments
Closed

Commands not found on Debian Buster ('init' is not a stestr command.) #336

ianw opened this issue Oct 18, 2022 · 4 comments
Labels
bug

Comments

@ianw
Copy link

ianw commented Oct 18, 2022

Issue description

I'm not exactly sure what is going on, but trying to install this an Debian Buster environment (that's where this test is failing), it seems like stestr can't find it's commands.

$ docker run -it  debian:buster /bin/bash

# apt-get update && apt-get install python3 python3-venv

# python3 --version
Python 3.7.3

# python3 -m venv /tmp/venv

# /tmp/venv/bin/pip install stestr
...
Successfully installed PrettyTable-3.4.1 PyYAML-6.0 attrs-22.1.0 autopage-0.5.1 cliff-3.10.1 cmd2-2.4.2 extras-1.0.0 fixtures-4.0.1 future-0.18.2 importlib-metadata-5.0.0 pbr-5.10.0 pyparsing-3.0.9 pyperclip-1.8.2 python-subunit-1.4.0 stestr-4.0.1 stevedore-3.5.1 testtools-2.5.0 typing-extensions-4.4.0 voluptuous-0.13.1 wcwidth-0.2.5 zipp-3.9.0
# /tmp/venv/bin/stestr init
stestr: 'init' is not a stestr command. See 'stestr --help'.
Did you mean one of these?
  help

# /tmp/venv/bin/stestr help
...
Commands:
  complete  print bash completion command (cliff)
  help  print detailed help for another command (cliff)

There don't seem to be any errors even in debug mode

# /tmp/venv/bin/stestr --debug -v init
initialize_app
stestr: 'init' is not a stestr command. See 'stestr --help'.
Did you mean one of these?
  help

For reference this appeared in Zuul testing @ https://zuul.opendev.org/t/zuul/build/3f94b03ab2fe414ab9447e6574a7794c/console#1/9/13/debian-buster
@ianw ianw added the bug label Oct 18, 2022
@ianw
Copy link
Author

ianw commented Oct 18, 2022

A failing run (https://zuul.opendev.org/t/zuul/build/3f94b03ab2fe414ab9447e6574a7794c/console)

Successfully installed PrettyTable-3.4.1 PyYAML-6.0 attrs-22.1.0 autopage-0.5.1 cliff-3.10.1 cmd2-2.4.2 extras-1.0.0 fixtures-4.0.1 future-0.18.2 importlib-metadata-5.0.0 pbr-5.10.0 pyparsing-3.0.9 pyperclip-1.8.2 python-subunit-1.4.0 six-1.16.0 stestr-2.5.1 stevedore-3.5.1 testtools-2.5.0 typing-extensions-4.4.0 voluptuous-0.13.1 wcwidth-0.2.5 zipp-3.9.0

A passing run (https://zuul.opendev.org/t/zuul/build/34d8dae0dd944dffaa0b704cd9e1e061/console)

Successfully installed PrettyTable-3.4.1 PyYAML-6.0 attrs-22.1.0 autopage-0.5.1 cliff-3.10.1 cmd2-2.4.2 extras-1.0.0 fixtures-4.0.1 future-0.18.2 importlib-metadata-4.12.0 pbr-5.10.0 pyparsing-3.0.9 pyperclip-1.8.2 python-subunit-1.4.0 six-1.16.0 stestr-2.5.1 stevedore-3.5.0 testtools-2.5.0 typing-extensions-4.3.0 voluptuous-0.13.1 wcwidth-0.2.5 zipp-3.8.1

I guess the difference here is importlib-metadata from 4.12.0 -> 5.0.0 and ``zipp```

@ianw
Copy link
Author

ianw commented Oct 18, 2022

Downgrading this does seem to work

# /tmp/venv/bin/pip install importlib-metadata===4.12.0
Collecting importlib-metadata===4.12.0
  Downloading importlib_metadata-4.12.0-py3-none-any.whl (21 kB)
Requirement already satisfied: zipp>=0.5 in /tmp/venv/lib/python3.7/site-packages (from importlib-metadata===4.12.0) (3.9.0)
Requirement already satisfied: typing-extensions>=3.6.4 in /tmp/venv/lib/python3.7/site-packages (from importlib-metadata===4.12.0) (4.4.0)
Installing collected packages: importlib-metadata
  Attempting uninstall: importlib-metadata
    Found existing installation: importlib-metadata 5.0.0
    Uninstalling importlib-metadata-5.0.0:
      Successfully uninstalled importlib-metadata-5.0.0
Successfully installed importlib-metadata-4.12.0
root@7398f2aafb21:/# /tmp/venv/bin/stestr help
...
Commands:
  complete  print bash completion command (cliff)
  failing  Show the current failures known by the repository.
  help  print detailed help for another command (cliff)
  history list  List the the run history in a repository.
  history remove  Remove a run from the history
  history show  Show the contents of a single run in the history
  init  Create a new repository.
  last  Show the last run loaded into a repository.
  list  List the tests for a project.
  load  Load a subunit stream into a repository.
  run  Run the tests for a project and store them into the repository.
  slowest  Show the slowest tests from the last test run.

I also tried this in a fresh venv making sure to pre-upgrade pip & setuptools in the venv, but that didn't seem to make a difference to the behaviour

@ianw
Copy link
Author

ianw commented Oct 18, 2022 •
edited
Loading

This has now led me to

python/importlib_metadata#411
python/importlib_metadata#409

which seems to be more or less the same problem; imports not quite working with Python 3.7 (which Debian Buster has).

It seems like stevedore might be involved in finding the commands? But 3.5.1 has a fix for this

https://opendev.org/openstack/stevedore/commit/143a3e9f0716690be7343d4d083f65d7624b3d2e

however clearly it's not working. Still unclear what the failing component is ...

@ianw
Copy link
Author

ianw commented Oct 18, 2022

I think this is ultimately a stevedore issue https://review.opendev.org/c/openstack/stevedore/+/861695

@ianw ianw closed this as completed Oct 18, 2022
openstack-mirroring pushed a commit to openstack/stevedore that referenced this issue Oct 19, 2022
@ianw
Order old importlib-metadata results by group
5189992 
A Debian Buster-based zuul-jobs test started failing when using stestr
recently [1].  Upon further investigation, this is a Python 3.7
environment which is affected by a recent breaking change to
importlib_metadata.

It seems stevedore worked around this with
Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
3.5.1 -- but I was still seeing the issue.

Upon further investigation, the "real_groups" dict being returned here
with importlib-metadata 4.12.0 is in buckets by group, e.g.

 {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                EntryPoint(name='bar', ... , group='group.one')],
  'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                EntryPoint(name='goo', ... , group='group.two')],
 }

This current code seems to return a dict with entry-points by thier
name, e.g.

 {'foo': EntryPoint(name='foo', ... , group='group.one),
  'bar': EntryPoint(name='bar', ... , group='group.one),
  'moo': EntryPoint(name='moo', ... , group='group.two),
  'goo': EntryPoint(name='goo', ... , group='group.two)
 }

This reorgansies the fixup routine to put entry-points in a bucket by
their group.  With this change, stestr is again finding it's command
plugins.

[1] mtreinish/stestr#336
[2] python/importlib_metadata#409

Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
openstack-mirroring pushed a commit to openstack/openstack that referenced this issue Oct 19, 2022
@ianw @openstack-gerrit
Update git submodules
915c871 
* Update stevedore from branch 'master'
  to 5189992d719ad15e0e3504947895bf5ba9dc7a1d
  - Order old importlib-metadata results by group
    
    A Debian Buster-based zuul-jobs test started failing when using stestr
    recently [1].  Upon further investigation, this is a Python 3.7
    environment which is affected by a recent breaking change to
    importlib_metadata.
    
    It seems stevedore worked around this with
    Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
    3.5.1 -- but I was still seeing the issue.
    
    Upon further investigation, the "real_groups" dict being returned here
    with importlib-metadata 4.12.0 is in buckets by group, e.g.
    
     {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                    EntryPoint(name='bar', ... , group='group.one')],
      'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                    EntryPoint(name='goo', ... , group='group.two')],
     }
    
    This current code seems to return a dict with entry-points by thier
    name, e.g.
    
     {'foo': EntryPoint(name='foo', ... , group='group.one),
      'bar': EntryPoint(name='bar', ... , group='group.one),
      'moo': EntryPoint(name='moo', ... , group='group.two),
      'goo': EntryPoint(name='goo', ... , group='group.two)
     }
    
    This reorgansies the fixup routine to put entry-points in a bucket by
    their group.  With this change, stestr is again finding it's command
    plugins.
    
    [1] mtreinish/stestr#336
    [2] python/importlib_metadata#409
    
    Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
openstack-mirroring pushed a commit to openstack/stevedore that referenced this issue Oct 19, 2022
@ianw @stephenfin
Order old importlib-metadata results by group
93f1e09 
A Debian Buster-based zuul-jobs test started failing when using stestr
recently [1].  Upon further investigation, this is a Python 3.7
environment which is affected by a recent breaking change to
importlib_metadata.

It seems stevedore worked around this with
Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
3.5.1 -- but I was still seeing the issue.

Upon further investigation, the "real_groups" dict being returned here
with importlib-metadata 4.12.0 is in buckets by group, e.g.

 {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                EntryPoint(name='bar', ... , group='group.one')],
  'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                EntryPoint(name='goo', ... , group='group.two')],
 }

This current code seems to return a dict with entry-points by thier
name, e.g.

 {'foo': EntryPoint(name='foo', ... , group='group.one),
  'bar': EntryPoint(name='bar', ... , group='group.one),
  'moo': EntryPoint(name='moo', ... , group='group.two),
  'goo': EntryPoint(name='goo', ... , group='group.two)
 }

This reorgansies the fixup routine to put entry-points in a bucket by
their group.  With this change, stestr is again finding it's command
plugins.

[1] mtreinish/stestr#336
[2] python/importlib_metadata#409

Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
(cherry picked from commit 5189992)
openstack-mirroring pushed a commit to openstack/stevedore that referenced this issue Oct 19, 2022
@ianw @stephenfin
Order old importlib-metadata results by group
6c9978a 
A Debian Buster-based zuul-jobs test started failing when using stestr
recently [1].  Upon further investigation, this is a Python 3.7
environment which is affected by a recent breaking change to
importlib_metadata.

It seems stevedore worked around this with
Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
3.5.1 -- but I was still seeing the issue.

Upon further investigation, the "real_groups" dict being returned here
with importlib-metadata 4.12.0 is in buckets by group, e.g.

 {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                EntryPoint(name='bar', ... , group='group.one')],
  'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                EntryPoint(name='goo', ... , group='group.two')],
 }

This current code seems to return a dict with entry-points by thier
name, e.g.

 {'foo': EntryPoint(name='foo', ... , group='group.one),
  'bar': EntryPoint(name='bar', ... , group='group.one),
  'moo': EntryPoint(name='moo', ... , group='group.two),
  'goo': EntryPoint(name='goo', ... , group='group.two)
 }

This reorgansies the fixup routine to put entry-points in a bucket by
their group.  With this change, stestr is again finding it's command
plugins.

[1] mtreinish/stestr#336
[2] python/importlib_metadata#409

Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
(cherry picked from commit 5189992)
(cherry picked from commit 93f1e09)
openstack-mirroring pushed a commit to openstack/stevedore that referenced this issue Oct 19, 2022
@ianw @stephenfin
Order old importlib-metadata results by group
1c12706 
A Debian Buster-based zuul-jobs test started failing when using stestr
recently [1].  Upon further investigation, this is a Python 3.7
environment which is affected by a recent breaking change to
importlib_metadata.

It seems stevedore worked around this with
Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
3.5.1 -- but I was still seeing the issue.

Upon further investigation, the "real_groups" dict being returned here
with importlib-metadata 4.12.0 is in buckets by group, e.g.

 {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                EntryPoint(name='bar', ... , group='group.one')],
  'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                EntryPoint(name='goo', ... , group='group.two')],
 }

This current code seems to return a dict with entry-points by thier
name, e.g.

 {'foo': EntryPoint(name='foo', ... , group='group.one),
  'bar': EntryPoint(name='bar', ... , group='group.one),
  'moo': EntryPoint(name='moo', ... , group='group.two),
  'goo': EntryPoint(name='goo', ... , group='group.two)
 }

This reorgansies the fixup routine to put entry-points in a bucket by
their group.  With this change, stestr is again finding it's command
plugins.

[1] mtreinish/stestr#336
[2] python/importlib_metadata#409

Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
(cherry picked from commit 5189992)
(cherry picked from commit 93f1e09)
(cherry picked from commit 6c9978a)
openstack-mirroring pushed a commit to openstack/stevedore that referenced this issue Oct 19, 2022
@ianw @stephenfin
Order old importlib-metadata results by group
7b48fff 
A Debian Buster-based zuul-jobs test started failing when using stestr
recently [1].  Upon further investigation, this is a Python 3.7
environment which is affected by a recent breaking change to
importlib_metadata.

It seems stevedore worked around this with
Ib9c2b0a14edea91e97d122d2ac93b650029f918e, which was released with
3.5.1 -- but I was still seeing the issue.

Upon further investigation, the "real_groups" dict being returned here
with importlib-metadata 4.12.0 is in buckets by group, e.g.

 {'group.one': [EntryPoint(name='foo', ... , group='group.one'),
                EntryPoint(name='bar', ... , group='group.one')],
  'group.two': [EntryPoint(name='moo', ... , group='group.two'),
                EntryPoint(name='goo', ... , group='group.two')],
 }

This current code seems to return a dict with entry-points by thier
name, e.g.

 {'foo': EntryPoint(name='foo', ... , group='group.one),
  'bar': EntryPoint(name='bar', ... , group='group.one),
  'moo': EntryPoint(name='moo', ... , group='group.two),
  'goo': EntryPoint(name='goo', ... , group='group.two)
 }

This reorgansies the fixup routine to put entry-points in a bucket by
their group.  With this change, stestr is again finding it's command
plugins.

[1] mtreinish/stestr#336
[2] python/importlib_metadata#409

Change-Id: I3496ab1dfa312b1098a869cdfd9a0c6f81653b28
(cherry picked from commit 5189992)
(cherry picked from commit 93f1e09)
(cherry picked from commit 6c9978a)
(cherry picked from commit 1c12706)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ianw