Maintenance status?

[stefan6419846]

What is the current maintenance status of this project? As far as I can see, the latest change to the main branch happened about a year ago, while some PRs are open for a longer time. The last release happened 1.5 years ago.

CI does not seem to run anymore after the latest Travis changes(?). Currently, Python 2.7 is still supported, although being EOL for over 3 years now, while recent Django versions > 3.0 are not tested at all.

[stefan6419846]

To add on this:

• Running the tests on Django 3.2.18 fails:

  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_callable_with_custom_method - TypeError: zip argument #1 must support iteration
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_event_added_from_instance - TypeError: zip argument #1 must support iteration
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_instance_save - TypeError: zip argument #1 must support iteration
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_with_custom_method - TypeError: zip argument #1 must support iteration
  

• For Django 4.1.7, the tests fail with another error, while additional errors arise:

  FAILED tests/test_mocks.py::TestMocks::test_exists_raises_error - TypeError: compiler() takes 3 positional arguments but 4 were given
  FAILED tests/test_mocks.py::TestMocks::test_mock_sql_raises_error - TypeError: compiler() takes 3 positional arguments but 4 were given
  FAILED tests/test_mocks.py::MockOneToOneTests::test_not_mocked - TypeError: compiler() takes 3 positional arguments but 4 were given
  FAILED tests/test_mocks.py::MockOneToManyTests::test_mock_is_removed - ValueError: 'Manufacturer' instance needs to have a primary key value before this relationship can be used.
  FAILED tests/test_mocks.py::MockOneToManyTests::test_not_mocked - ValueError: 'Manufacturer' instance needs to have a primary key value before this relationship can be used.
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_callable_with_custom_method - TypeError: 'int' object is not subscriptable
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_does_not_interfere_with_non_mocked_models - TypeError: compiler() takes 3 positional arguments but 4 were given
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_event_added_from_instance - TypeError: 'int' object is not subscriptable
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_instance_save - TypeError: 'int' object is not subscriptable
  FAILED tests/test_mocks.py::TestMockers::test_model_mocker_with_custom_method - TypeError: 'int' object is not subscriptable
  

[stphivos]

Hi @stefan6419846 , yes I rarely have time these days so I've been reviewing and merging PRs passing CI. I will create a new release dropping support for python 2.7 and try to restore CI some time this week. Also I would happily add new contributors to the project who actively use it on a regular basis and so anyone interested pls let me know.

[stefan6419846]

Thanks for the explanations. I am actively using it (although not with the full feature set), so I would be interested in helping maintaining the package to ensure it keeps working.

After some back-and-forth, especially with the TypeError stuff, it seems like I managed to get the self-tests pass again up to Django 4.1.7 (although these changes might break for Django 3.0). And yes, dropping EOL stuff like Python 2.7 or Django 1.11 seems like a good idea.

For the time being, I have pushed my changes to https://github.com/stefan6419846/django-mock-queries/tree/ci, which includes the aforementioned Django fixes as well as removing Python 2.7 support and migrating CI to GitHub Actions. Nevertheless, the tests do not use tox there at the moment, as I am not familiar enough with it and this has been irrelevant for the migration itself.

[stphivos]

Thanks @stefan6419846, I hadn't realized finding a replacement for travis was kinda necessary! Your example helped me migrate what is currently on master to GH actions just by dropping support for python 2.7 and 3.5. I have added you as a collaborator, when possible let's continue making improvements incrementally using PRs/reviews/etc?

[stefan6419846]

Thanks for the heads-up and the CI migration. In theory Travis still works, but the travis-ci.org version has been discontinued in favor of the travis-ci.com version; this required manual action to migrate stuff and communication has not always been clear regarding FOSS projects. As GitHub Actions started to provide native support for running CI stuff on GitHub itself, using these usually is the easiest one.

I am planning to create PRs with the fixes from my branch here as well in smaller parts, probably in the following order:

• Remove the existing Python 2 compatibility code (mock, six and the deprecated test assertions).
• Migrate some deprecated stuff (pytest in favor of py.test, flake8 as dedicated step as pytest-flake8 proved to lead to some issues after updates and such integrations are considered bad by the pytest developers).
• Test on the latest Django 3 and Django 4 versions and fix the corresponding tests.
• Update the used package versions and replace the pinned ones with their latest ones.

[stefan6419846]

@stphivos I am currently struggling with tox doing strange stuff on the django3-4 branch - maybe you have an idea?

Running the job at https://github.com/stphivos/django-mock-queries/actions/runs/4923852732/jobs/8796176268 for Django 2.2 (or Django 1.11) somehow installs Django 3.2.19:

py37-dj22-drf39 installed: asgiref==3.6.0,atomicwrites==1.4.1,attrs==23.1.0,certifi==2023.5.7,charset-normalizer==3.1.0,coverage==3.7.1,distlib==0.3.6,Django==3.2.19,django-mock-queries @ file:///home/runner/work/django-mock-queries/django-mock-queries/.tox/.tmp/package/1/django_mock_queries-2.1.7.zip#sha256=ffe8537c72445b1a9080579cda6578913a6d971659ff99b1b53bfb2d154ed4a1,djangorestframework==3.9.4,filelock==3.12.0,flake8==3.4.1,idna==3.4,importlib-metadata==6.6.0,mccabe==0.6.1,model-bakery==1.11.0,more-itertools==9.1.0,packaging==23.1,pkginfo==1.9.6,platformdirs==3.5.0,pluggy==0.13.1,py==1.11.0,pycodestyle==2.3.1,pyflakes==1.5.0,pypandoc==1.4,pytest==4.6.11,pytest-cov==2.4.0,pytest-django==3.1.2,pytest-flake8==0.7,pytz==2023.3,requests==2.30.0,requests-toolbelt==1.0.0,six==1.16.0,sqlparse==0.4.4,toml==0.10.2,tox==3.10.0,tqdm==4.65.0,twine==1.11.0,typing_extensions==4.5.0,urllib3==2.0.2,virtualenv==20.23.0,wcwidth==0.2.6,zipp==3.15.0

[stefan6419846]

After some back-and-forth, I finally managed to pin this down to an actual tox issue, which has been fixed in tox-dev/tox#2888. Starting with tox 4.4.0, we can add the following lines to the testenv section to install the correct package versions:

constrain_package_deps = true
use_frozen_constraints = false

Due to https://github.com/tox-dev/tox/blob/4.4.0/pyproject.toml#L24, this requires us to stop testing on Python 3.6 (which should be no big deal as it is EOL anyway and allows us to upgrade to ubuntu-2204 for the GitHub Actions as well).

I will probably push the corresponding commits tomorrow.

[stefan6419846]

Due to a conflict between the latest tox and flake8, I will stop testing on Python 3.7 (and Django 1.11) as well which is EOL in about a month anyway (https://devguide.python.org/versions/):

The conflict is caused by:
    pytest 7.3.1 depends on importlib-metadata>=0.12; python_version < "3.8"
    flake8 5.0.4 depends on importlib-metadata<4.3 and >=1.1.0; python_version < "3.8"
    tox 4.5.1 depends on importlib-metadata>=6.4.1; python_version < "3.8"

[stphivos]

Nice! I tried locally using 2 individual steps

pip install -r requirements/dev.txt
pip install "Django~=2.2.1" "djangorestframework~=3.9.2"

and then checking it looks correct

$ pip freeze | grep jango
Django==2.2.28
djangorestframework==3.9.4

I had not imagined this to be a tox issue. The proposed changes look good, I will just try to push the latest working tags/releases for each of py27, py35, py36 and py37 to pypi.

[stefan6419846]

The proposed changes look good, I will just try to push the latest working tags/releases for each of py27, py35, py36 and py37 to pypi.

Did you already have time for this? We might want to do a regular release as well, incorporating the latest changes.

[stphivos]

Yes just published v2.2.0 release to github and pypi. So far i've been creating new releases after accumulating functionality from a couple or more PRs or when somebody requested it. It wasn't too often so I hadn't come up with any regular procedure. Do you propose something specific?

[stefan6419846]

Thanks. For me the current procedure is fine, although especially with sparse changes, it might make sense to generate a release shortly after to avoid waiting for long periods until an actual release is published.