kaste / mockito-python

Mockito is a spying framework
MIT License
123 stars 12 forks source link

No longer working with Python 2.7 #64

Closed rob-spoor closed 2 years ago

rob-spoor commented 2 years ago

For a legacy project I still need to use Python 2.7. I recently upgraded to the latest version of mockito, but then started getting errors:

ImportError: Failed to import test module: test_web_hooks_helper
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/local/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "/my-file.py", line 6, in <module>
    from mockito import *
  File "/usr/local/lib/python2.7/site-packages/mockito/__init__.py", line 24, in <module>
    from .mockito import (
  File "/usr/local/lib/python2.7/site-packages/mockito/mockito.py", line 23, in <module>
    from . import invocation
  File "/usr/local/lib/python2.7/site-packages/mockito/invocation.py", line 21, in <module>
    from . import matchers
  File "/usr/local/lib/python2.7/site-packages/mockito/matchers.py", line 62, in <module>
    from abc import ABC, abstractmethod
ImportError: cannot import name ABC

This is the offending line:

from abc import ABC, abstractmethod

The cause of the failure is the different way that abc is used. See https://docs.python.org/2.7/library/abc.html#module-abc for more information.

I see two different ways to handle this:

  1. Find some way to use abc and abstractmethod for both Python 2.7 and 3.x
  2. Simply drop support for Python 2.7

As for me, my workaround was to use version 1.3.0, which is the last version to not use the incompatible import.

rob-spoor commented 2 years ago

I don't know if it's possible, but ideally the current versions 1.3.1 and up should not report working for Python 2.7 on PyPI. Otherwise people are forced to use mockito<1.3.1 like I was, as pip will automatically try to download the broken (for Python 2.7) version 1.3.4.

kaste commented 2 years ago

Well, a sudden drop from 1.3.0 to 1.3.1 is not nice nor was intended. Fact is we don't run tests (CI) against anything before '3.5'. And actually I dropped old python version in 27e5587 (Update python version classifiers) but forgot(?) '2.7'.

I really don't remember. Probably I did not want to drop 2.7 suddenly but also did not find a test environment for it quickly enough.

So

  1. Can I run the github action with 2.7. Are the test then green?
  2. Can I fix the classifiers for these releases now, after the fact, or are they immutable?
kaste commented 2 years ago

It seems like the classifiers sections is not used by pip at all. It is just "informational". I could make a fixing release when I apply #66 but actually I don't know how to tell which python versions this package is supposed to work for. And how to change that for the older releases.

rob-spoor commented 2 years ago

I checked yesterday, but it doesn't appear to be possible to change older versions.

I also assumed that the classifiers would limit to what pip would allow, but apparently it doesn't. I found https://stackoverflow.com/questions/45778790/specifying-the-minimum-python-version-required-for-a-module-in-pip which says python_requires can be used.

kaste commented 2 years ago

For reference: https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires

kaste commented 2 years ago

v1.3.5 now supports 2.7 again.

I think one can fix old published versions doing a "post" release. For example, a 1.3.1.post1 is meant to be a fixup release pip should prefer automatically. (https://peps.python.org/pep-0440/#post-releases) Questionable if this is necessary here. 🤔

rob-spoor commented 2 years ago

If there is a working 1.3.5 I don't think that will be necessary.