migrate setup.py to pyproject.toml

[deronnax]

hmm funny, I don't have this circular/partial import error on my computer through tox.

[john-kurkowski]

Hey, thanks for the contribution!

No description provided.

What brought this PR about?

[deronnax]

we use this project and I found it is still using setup.py, so I offer the conversion to setup.cfg, which is superior

[john-kurkowski]

Do you have any resources about setup.cfg's superiority? Is setup.py prior to this PR causing problems?

I've been using pyproject.toml in personal projects. I thought that was the new hotness. But after cursory Googling, the winning project configuration format is unclear to me! 😅

[john-kurkowski]

hmm funny, I don't have this circular/partial import error on my computer through tox.

I reproduced the failure by deleting the local, ignored file tldextract/_version.py. I wonder if there's a way to clean the file for tox tests, to make reproducing the failure easier. Anyway, in 2b42b48, I restored some lost code from the transition. Tests pass now.

According to setuptools_scm's older docs, its configuration must remain in setup.py. (The newest release of their docs only give pyproject.toml instructions.)

[deronnax]

Do you have any resources about setup.cfg's superiority?

https://setuptools.pypa.io/en/latest/references/keywords.html: Users are strongly encouraged to use a declarative config either via setup.cfg or pyproject.toml and only rely on setup.py if they need to tap into special behaviour that requires scripting (such as building C extensions).

Is setup.py prior to this PR causing problems?

Not per se, but its paradigm is deprecated (executing arbitrary code just to describe a package), it's more complex than setup.cfg, allows for error to slip in and support will eventually be dropped in a not-so-far future.

I've been using pyproject.toml in personal projects. I thought that was the new hotness

It is. But the change is (quite) bigger than the simple setup.py -> setup.cfg migration (for which semantics remain the same, setup.cfg is just a static version of setup.py) . There are tools to automaticaly migrate from setup.cfg to pyproject.toml.

[deronnax]

OK I just discovered the _version.py was generated, that's why it's breaking.

[deronnax]

And setuptools_scm seems to not work only with setup.cfg, arg. I will either spend some time trying to do the conversion to pyproject.toml or close the PR. Sorry for the noise.

[john-kurkowski]

Thank you for the explanation on the different config options! That makes sense. I'm open to migrating away from the very legacy setup.py approach. However, rather than migrate setup.py to setup.cfg, and (soon?) migrate setup.cfg to pyproject.toml, I'd rather leap to pyproject.toml directly, to save some churn. I'd welcome that conversion. 🙏

OK I just discovered the _version.py was generated, that's why it's breaking.

Yes, I fixed it in 2b42b48, which you seemed to force-push over. 😉 If we're not doing setup.cfg anyway, no sweat.

[deronnax]

Hmmm, there you go. Only the pypy job is failing, I don't really get why but I guess it has to do with just being too old versions of pypy or something similar. Since python 3.7 is EOL for 3 weeks now, you might want considering to just drop the support. (I can't even install pypy3.7 on my M2 MacBook).

[deronnax]

Wow. Here you go. You don't even have to drop support for python 3.7, just use the latest 3.7 of pypy, lucky you. Don't forget to squash commits, of course.

[john-kurkowski]

Beautiful! Thank you!