migrate to pyproject.toml

[p-r-a-v-i-n]

i think we should move to pyproject.toml bcs maintaining pyproject.toml is easier for long run.
it also add simplicity and remove complexity.

i have shifted all the dependency to single file.
we no longer would need setup.py, requirements , flak8 files anymore.

[p-r-a-v-i-n]

I have produce build on master and feature branch and have attached both the build below and screenshot which will show the diff in both the build.

dclick-updated-build.tar.gz
dclick-original-build.tar.gz

[p-r-a-v-i-n]

updated build

[FlipperPA]

@p-r-a-v-i-n THANK YOU! This is something I've been wanting to dive into for a long while, but have been delayed. I'm not going to get a chance to review this in depth until January (getting married). If anyone else in @django-commons/django-click want to take a look, I wouldn't object!

[FlipperPA]

I want to ping @ulgens in particular to recognize the great work done lately, and give an opportunity to review.

[ulgens]

Thanks @FlipperPA . I added a couple of small notes but other than those, it looks amazing.

Edit: I added couple comments after giving my approval, sorry 😬 I think those comments require only a minimal amount of effort and I can help to handle them if needed.

[ulgens]

Both #65 and #64 changes the supported Django versions. If they get merged first, this PR will need a rebase.

[ulgens]

Just realized, these are migrated from requirement-dev.txt. Not sure why the new group name is docs.

[p-r-a-v-i-n]

Hi @ulgens ,
what i noticed that we have been using requirement-dev.txt to install the all dependencies including requirement-test.txt. so i broke down this into groups , currently there are 3 groups. all, test, docs.

why group name docs

most of the packages except automation and packaging were related to docs. thats why i choose it.

and thanks that you spotted this . after going through this again i noticed that we don't need wheel and check-manifest now

[ulgens]

I'm curious if the setuptools selection over other tools like hatchling was on purpose. Just asking to learn, I'm okay with the selection if it's working fine.

[p-r-a-v-i-n]

nice question. well even i'm also learning and what i have found that setuptools is the most compatible drop-in replacement for migrating from setup.py.

• currently the setup.py file uses dyanamic python code like Setup.version() , file reading logic this may not be possible in hatchling
• I have removed the MANIFEST.in currently but there might be chance where we would need to add MANIFEST.in for some reason so hatchling don't support it.
• setuptools has low risk when migrating from setup.py file.

[ulgens]

Nitpick: I'd recommend having alphabetical sorting between groups. Helps to minimize cognitive load and it doesn't seem there is a strong reason to prioritize test group.

[p-r-a-v-i-n]

i will update it.

[ulgens]

Let's follow the same ordering here with the groups below.

[FlipperPA]

I've merged in the Django upgrades and the redundant packages, so we can rebase now. 👍

[ulgens]

@FlipperPA One last PR before the rebase: #65

[FlipperPA]

@FlipperPA One last PR before the rebase: #65

Done!

[FlipperPA]

We can leave this for a follow-up action, but after we're done here, we can also migrate the tox.ini configuration into pyproject.toml. I'm not sure it would be cleaner, but it would eliminate a file:

[tool.tox]
legacy_tox_ini = """
[tox]
envlist =
    dj{42,52,60,main}

[gh-actions]
django =
    4.2: dj42
    5.2: dj52
    6.0: dj60
    main: djmain

[testenv]
package = editable
passenv = LC_ALL, LANG, LC_CTYPE
setenv =
    DJANGO_SETTINGS_MODULE=testprj.settings
    PYTHONPATH={toxinidir}/djclick/test/testprj
deps =
    dj42: django>=4.2,<4.3
    dj52: django>=5.2,<5.3
    dj60: django>=6.0,<6.1
    djmain: https://github.com/django/django/archive/main.tar.gz
commands =
    pip install --group test
    pytest -rxs --cov-report= --cov-append --cov djclick {posargs:djclick}
"""

[p-r-a-v-i-n]

I might be completely wrong here but i have feeling that rules set could be improve.
I don't see the linear history.

[ulgens]

@FlipperPA If that's okay, my vote about tox settings is to keep them separate. I prefer to keep ruff settings in a separate file too. pyproject.toml file can hold settings for lots of tools but it also can get out of control very easily.

@p-r-a-v-i-n That's the result of having merge commits with not-rebased branches. I prefer "rebase merge only" in work projects to keep the history completely linear, or we can enable "require branches to be up to date before merging" - I didn't know that was a general concern.

[ulgens]

The comment is no longer needed.

[ulgens]

Let's follow the same ordering here with the groups below.

[FlipperPA]

@ulgens I'm all good with keeping tox.ini and ruff settings separate, especially since we have a more-complex-than-most pyproject.toml.

I'm also a fan of rebase merges, but both methods have their shortcomings. If you've ever gotten caught in step-by-step conflict resolution, it isn't fun. :) There's also squash-and-merge, which loses some granularity but keeps commit histories shorter, clean, and linear.

I don't lose sleep over it, so if we want to enforce one way over the other, we can do replays instead of merge or fast-forwards.