Running setup.py directly is deprecated

[cclauss]

Running python3 setup.py directly as a script is deprecated.

• https://setuptools.pypa.io/en/latest/deprecated/commands.html
• https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html#summary

Let's use python3 -m build and python3 -m pip install instead of directly running setup.py.

[Nusnus]

LGTM

[cclauss]

This PR is draft because I need to do Makefile but will do that in the next few hours.

[ulgens]

I'm not sure venv management should be covered here. There are tons of ways of to manage a venv, and forcing one in a tutorial ends up badly in my experience. Just a mention of a venv should be enough, as is before.

[cclauss]

This is Python's built-in way of creating and enabling a venv. Users are free to choose alternative methods but I prefer explicit steps here to document what we know works and avoid issues being opened around implicit steps.

[ulgens]

I prefer explicit steps here to document

This can be easily paraphrased as "pushing an opinionated tooling", which worries me. IMO, for anything related to venv, considering how every detail of that topic is open for a million different debates, it's better to keep an equal distance to all options.

Of course, you can ignore my comment; it's not a big thing, but I believe these types of details are more important than most people care for.

[cclauss]

Opinionated tooling would have been a suggestion to use uv. 😄

I do tons of responding to Node.js and node-gyp issues. It is there (and elsewhere) that I have learned the hard way that incomplete directions and assumptions lead to long-winded discussions.

it's better to keep an equal distance to all options.

I think suggesting the one that is built-in and requires zero third-party software is relatively safe.

[ulgens]

Same here: #737 (comment) With these changes, it looks like the steps are more about venvs, not the actual goal of the doc.

[ulgens]

Doesn't it make better sense with "yet" at end of the sentence, as the before?

[cclauss]

It felt like a dangling participle when I read it. (But I would bet dollars to doughnuts that it is not a participle. 😃)

[cclauss]

OK... This is now ready for review. The only thing I am unclear about is the Makefile lines 69 and 71 but we will need to debug them to make the release process happen. Let me know if you want an extra pair of eyes for the release process.

[deronnax]

I went to look into setuptools' changelog what these register and upload --sign commands that I never saw before were, and setuptools tells us you can forget about them and just do with twine pypa/setuptools#1898.
So I think you can just remove these two lines. If you want, you can test locally that it still work as you expect by making twine point to the test version of PyPI: https://test.pypi.org/

[Nusnus]

LGTM

[Nusnus]

I went to look into setuptools' changelog what these register and upload --sign commands that I never saw before were, and setuptools tells us you can forget about them and just do with twine pypa/setuptools#1898.
So I think you can just remove these two lines. If you want, you can test locally that it still work as you expect by making twine point to the test version of PyPI: https://test.pypi.org/

I like this idea although I've never used the test pypi index before. @cclauss I'm up for testing it if you're interested and if it works deploy to normal pypi afterwards.

[deronnax]

I checked out the PR to test and I got a problem:

make
Makefile:68: *** missing separator.  Stop.

On line 68, you used space for indentation instead of tabs. Makefile only accepts tabs for indentation.

Errors were found

[amweiss]

Even with the above fixes, the steps in the README do not work for me locally:

 => [base] exporting to image                                                                                                                                                  0.0s
 => => exporting layers                                                                                                                                                        0.0s
 => => writing image sha256:5fe8d8101eb68554633bd1a71f3197d691c35206b3fe0a4bf7254a8fe3a3d0ab                                                                                   0.0s
 => => naming to docker.io/library/django-celery-beat-base                                                                                                                     0.0s
 => [celery-beat internal] load .dockerignore                                                                                                                                  0.0s
 => => transferring context: 2B                                                                                                                                                0.0s
 => [celery-beat internal] load build definition from Dockerfile                                                                                                               0.1s
 => => transferring dockerfile: 325B                                                                                                                                           0.0s
 => ERROR [celery-beat internal] load metadata for docker.io/library/django-celery-beat_base:latest                                                                            2.4s
 => [django internal] load .dockerignore                                                                                                                                       0.0s
 => => transferring context: 2B                                                                                                                                                0.0s
 => [django internal] load build definition from Dockerfile                                                                                                                    0.1s
 => => transferring dockerfile: 315B                                                                                                                                           0.0s
 => [celery-beat auth] library/django-celery-beat_base:pull token for registry-1.docker.io                                                                                     0.0s
------
 > [celery-beat internal] load metadata for docker.io/library/django-celery-beat_base:latest:
------
failed to solve: django-celery-beat_base: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

However, this is also true on the main branch as well as v2.5.0 at this point, so I am unsure what the best path forward would be.

[deronnax]

What you are posting is seemingly a docker error, and there is no docker in the Makefile, so I am not sure how you got it. For the Makefile, I was able to have make release to work, that's what interests us here.

Regarding the docker error, it's something trivially wrong in the dockerfiles: the Dockerfiles ask for a tagged base image that is never generated, hence the error. It probably never worked.

[auvipy]

as the oldest maintainer of the project, I would like to review it in detail before merging. hope you are OK with it.

[Nusnus]

@auvipy

as the oldest maintainer of the project, I would like to review it in detail before merging. hope you are OK with it.

Please be aware that the release for Django 5 support is blocked on this PR: #680

From my understanding this PR is also ready already, even if not everything is perfect.

Many are expecting a release soon, IMHO I believe we should proceed - let me know what I can do to accelerate the merge, how may I help?

P.S
I'm up for a zoom session or anything online to work together - let me know bro 🤙

[ulgens]

Many are expecting a release soon, IMHO I believe we should proceed - let me know what I can do to accelerate the merge, how may I help?

I also agree that a new release with Django 5.0 support is needed, but I don't think this PR is a blocker.

[Nusnus]

I also agree that a new release with Django 5.0 support is needed, but I don't think this PR is a blocker.

Makes sense actually, reviewing again the changes of this PR.

If you agree @cclauss, we can move forward and continue with the PR after @auvipy gives us his feedback to proceed in both paths.

[deronnax]

Looks good to me. Migrating the setup.py to a declarative form could be the next step, wdyt?

[amweiss]

With these changes in place, if you want to make the README work correctly or the docker compose actions work, the following changes are still needed. Add the following lines:

      tags:
        - django-celery-beat_base:latest

below https://github.com/cclauss/django-celery-beat/blob/bc4684b174d6d5c766dffc3a6f74241e9ca113f7/docker-compose.yml#L10-L11

so the base definition looks like the following:

  base:
    build:
      context: .
      dockerfile: docker/base/Dockerfile
      tags:
        - django-celery-beat_base:latest
    command: ["sleep", "inf"]

After that, the docker-compose up --build command will work as it's stated in the README.

[amweiss]

This worked for me now.

[cclauss]

This sat un-reviewed to too long until setuptools changes brokesetup test in

• Update test suite to use pytest, remove related in setup.py #771
• Installation error setuptools.command.test for version 2.6.0 #772

Let's get some maintainers reviews on this please.

[auvipy]

good job!

[browniebroke]

While this is fresh in everyone's head, would now be a good time to make a new release? The change in setuptools was reverted, but it's been deprecated for years, so it will be removed at some point in... Would be nice to give plenty of time for upgrading.

Thanks!

[cclauss]

😉 #749 (comment)