search

brandon-rhodes / python-jplephem

Python version of NASA DE4xx ephemerides, the basis for the Astronomical Alamanac
MIT License
108 stars 28 forks source link

Stop using the deprecated distutils #56

Open avalentino opened 1 year ago

avalentino commented 1 year ago

Use setuptools instead.

brandon-rhodes commented 1 year ago

Am I correct that this will break users who attempt to install from .tar.gz but who don't have setuptools installed, but only their system's standard Python?

avalentino commented 1 year ago

Am I correct that this will break users who attempt to install from .tar.gz but who don't have setuptools installed, but only their system's standard Python?

Yes, correct. The mossing part is a pyproject.toml declaring build requirements. I can provide it.

Actually we could move most of the content of the current setup.py to the pyproject.toml file. If you agree I can provide a patch also for that.

miccoli commented 1 year ago

Am I correct that this will break users who attempt to install from .tar.gz but who don't have setuptools installed, but only their system's standard Python?

Yes, but on the other side, under python 3.12 (to be released 2023-10-02) the build will fail with ModuleNotFoundError: No module named 'distutils'.

brandon-rhodes commented 1 year ago

I've been pondering this week whether to add a try...except so that Python 2 installation keeps functioning, or whether to break Python 2 but maybe have a try…except that prints out a message that says to open an issue here on GitHub if you need Python 2 to be supported. If no issue is ever opened, then I could move forward without distutils still being in the code anywhere! If instead someone opened an issue, I could quickly release a new version that restores Python 2 compatibility, and I'd finally have an issue to point at the next time someone said "but no one uses Python 2 any more!" to show them that in the real world of systems and users, it's still in use.

And yet —

If the next install fails for someone, would they really go create a GitHub account and go through the work of figuring out how to create an issue? Or would they just install the previous version of jplephem instead, assuming they could figure out the magic incantation to do that (and assuming they could figure out what the previous version had been)? Or would they give up entirely?

The problem with breaking things for users is that it can be traumatic for the user while never signalling the developer that something is wrong.

I'm likely to take the first option: a try...except that keeps things working for Python 2. Because I myself tend to be almost furious when other developers break things for me gratuitously, and so I don't want to do that for others. But I'll think about it another day or two. Hopefully I'll decide this weekend!

avalentino commented 1 year ago

Hi @brandon-rhodes, sorry, I have probably misunderstood your first comment. By the way I would like to point out that dropping distutils does not mean dropping Python 2 (although I disabled it in CI because GHA no longer supports it).

setuptools v44.x is the latest version compatible with Python 2 I will revert the last commit ("Move project metadata to pyproject.toml") so that the new setup.py will be fully compatible with Python 2 + setuptools v44.x.

Regarding the scenario in which setuptools is not installed, the change should be transparent to users installing the package via pip thanks to the new pyproject.toml file.

The only scenario which is not covered is the one in which the user runs the setup.py script directly:

$ python setup.py install

For this case, using the try...except solution that you suggest is for sure the simpler option. I will implement it in a new commit.

By the way I would strongly recommend to deprecate the direct invocation of the setup.py script in favour of more modern installation methods. Few lines in the release notes should suffice IMHO.