Transition from setup.py to pyproject.toml #199

wshanks · 2024-03-10T04:59:55Z

Move static package configuration from setup.py to pyproject.toml
- Minimal changes were made to the configuration, so it still lists Python 2.7 as the minimum version, though it hasn't been tested what the minimum version of Python is that can install the package with a pyproject.toml file and no setup.py.
- The future dependency was restricted to python < 3.1' since it is not needed with Python 3 and is not actively maintained.
Merge long description content in setup.py into README.rst
Capture development dependencies listed in setup.py in requirements-dev.txt
Save change log which was in long description in setup.py in its own file, CHANGES.rst.

wshanks · 2024-03-10T13:07:35Z

This incorporates the change I had proposed in #168.

andrewgsavage · 2024-03-10T13:14:47Z

pyproject.toml

+    "Operating System :: OS Independent",
+    "Programming Language :: Python",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.1",


should python <3.8 be included here?

the development plans discussions lists

Support Python 3.8 to 3.12

So you could remove the future dependency and early python versions here, or that can be done in another PR.

Yes, it seemed like there was agreement to move to 3.8+. I started to do that here but then thought I would do it in a separate PR since it is a consequential change and it would be nice to have its own PR for it for someone to comment on. I think we can just make a quick follow up to drop the lines below 3.8.

There is also the question of requires-python. pip obeys that line, so we may not want to set it to >=3.8 if we want to allow Python 3.6 until we intentionally break compatibility, even if we are not actively testing it. I left it at 2.7 here, but I think this change breaks the ability to install the package in Python 2 already since I don't think the last versions of pip and setuptools for Python 2 can install a project using pyproject.toml.

Maybe I should make a PR to drop Python 2 and early Python 3 to merge before this PR so there is a clear progression. I did this part first because I thought it was easier (not needing decide what line to draw with 3.6/3.8).

I just quickly researched how requires-python works here. It looks like if we set requires-python to >=3.8 then if someone did pip install uncertainties while having Python 3.7 then pip/pypi would NOT let them install the newest version of uncertainties, but it would walk backwards finding older versions until one did not have 3.7 excluded by requires-python.

I think I agree with you we shouldn't set it until we know we've broken compatibility. But I guess I would suggest that we try to set it exactly when we do know we break compatibility. That is, if we know the code is broken for Python 3.7 we should set requires-python = ">=3.8" at that time. That way users hit the error as soon as possible (i.e. at install time). I guess what would happen for that user is pip/pypi would resolve an old enough version of uncertainties that is compatible with their python version. This combined with messaging in the docs about which versions of uncertainties support which versions of Python seems like enough notification to users about versioning considerations.

wshanks · 2024-03-10T18:50:49Z

Okay, I made a separate PR (#200) about updating the supported versions of Python and then rebased this one on that. So we can agree there on how to specify Python versions and then make this change. In that PR, I left some opening for continuing to work with older Python versions, but I think this change will preclude easily installing the package with Python 2.

wshanks · 2024-03-10T18:52:27Z

pyproject.toml

+    fast calculation of derivatives').\
+    """
+readme = "README.rst"
+requires-python = ">=3.1"


Because I think this change to pyproject.toml precludes easily installing the package with Python 2 (I don't think there is pyproject.toml support in the libraries left in Python 2 though maybe there are forks maintained somewhere with support for it), I set requires-python>=3.1. pip respects this value so I didn't want to set it too high, so for example someone could install the package with Python 3.6 even though we only test 3.8+. Alternatively, we could just remove this line.

jagerber48 · 2024-03-10T19:23:47Z

I wonder if we should actually release #200 prior to merging in this PR to master. That way there is one versioned release that announces dropping support for earlier versions of python and then a different release that actually drops some versions.

newville · 2024-03-11T02:45:22Z

@wshanks @jagerber48 I would be opposed to trying to support Python below 3.8 or claiming that there is support for Python versions that are past their end of life.

We could probably have a setup.py of

import setuptools
setuptools.setup()

I am not going to be able to keep up with multiple PRs and multiple discussion topics per week, especially multiple PRs over a weekend.

wshanks · 2024-03-11T03:50:58Z

@wshanks @jagerber48 I would be opposed to trying to support Python below 3.8 or claiming that there is support for Python versions that are past their end of life.

I put some thoughts in #200 (comment). I am open to whatever in this regard. For me, it's easier just to support officially supported versions, but if there is demand I don't see anything strongly pushing for dropping specific versions.

We could probably have a setup.py of
import setuptools
setuptools.setup()

I wondered if that would help with anything but wasn't sure. Maybe if something downstream repackaging the project uses python setup.py still instead of python -m build or pip build?

I am not going to be able to keep up with multiple PRs and multiple discussion topics per week, especially multiple PRs over a weekend.

Sorry -- I am just trying to keep momentum going on the clean up of the project, but there is no rush to get anything in on my part. The only potential pressure is too many conflicting PRs building up unmerged.

* Move static package configuration from setup.py to pyproject.toml - Minimal changes were made to the configuration, so it still lists Python 2.7 as the minimum version, though it hasn't been tested what the minimum version of Python is that can install the package with a pyproject.toml file and no setup.py. - Drop the `future` dependency since it is not needed with Python 3. * Merge long description content in setup.py into README.rst * Capture development dependencies listed in setup.py in requirements-dev.txt * Save change log which was in long description in setup.py in its own file, CHANGES.rst.

codecov · 2024-03-15T16:27:09Z

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (master@642c503). Click here to learn what that means.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #199   +/-   ##
=========================================
  Coverage          ?   95.49%           
=========================================
  Files             ?       17           
  Lines             ?     2085           
  Branches          ?        0           
=========================================
  Hits              ?     1991           
  Misses            ?       94           
  Partials          ?        0

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

wshanks · 2024-03-15T16:55:25Z

With #200 merged, I rebased this on master since I had previously based it on #200's branch.

We can merge it whenever we are ready to break Python 2 compatibility.

I didn't add a setup.py file. My understanding is that running python setup.py has been deprecated for several years now. setup.py is still invoked for more complicated projects that need to set metadata dynamically, but we don't need that here currently. We could still add it if someone thinks it is important.

newville · 2024-03-15T17:50:58Z

@wshanks OK, great, and thanks. I think we may not be done with all of this, but let's end Python 2 support!!

This reverts commit e9b82f0.

wshanks force-pushed the pyproject branch from 9465816 to c83cb08 Compare March 10, 2024 12:57

andrewgsavage reviewed Mar 10, 2024

View reviewed changes

andrewgsavage approved these changes Mar 10, 2024

View reviewed changes

wshanks force-pushed the pyproject branch from c83cb08 to 2aadc39 Compare March 10, 2024 18:47

wshanks commented Mar 10, 2024

View reviewed changes

wshanks mentioned this pull request Mar 11, 2024

Drop official support for Python versions before 3.8 #200

Merged

wshanks force-pushed the pyproject branch from 2aadc39 to 809f464 Compare March 12, 2024 20:17

wshanks force-pushed the pyproject branch from 8172f25 to 375efdb Compare March 15, 2024 16:26

newville merged commit e9b82f0 into lmfit:master Mar 15, 2024
18 checks passed

newville added a commit that referenced this pull request Apr 1, 2024

Revert "Transition from setup.py to pyproject.toml (#199)"

4f2693f

This reverts commit e9b82f0.

wshanks mentioned this pull request May 21, 2024

Move to setup.cfg / pyproject.toml #147

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Transition from setup.py to pyproject.toml #199

Transition from setup.py to pyproject.toml #199

wshanks commented Mar 10, 2024 •

edited

Loading

wshanks commented Mar 10, 2024

andrewgsavage Mar 10, 2024 •

edited

Loading

andrewgsavage Mar 10, 2024

wshanks Mar 10, 2024

jagerber48 Mar 10, 2024 •

edited

Loading

wshanks commented Mar 10, 2024

wshanks Mar 10, 2024 •

edited

Loading

jagerber48 commented Mar 10, 2024

newville commented Mar 11, 2024

wshanks commented Mar 11, 2024

codecov bot commented Mar 15, 2024 •

edited

Loading

wshanks commented Mar 15, 2024

newville commented Mar 15, 2024

Transition from setup.py to pyproject.toml #199

Transition from setup.py to pyproject.toml #199

Conversation

wshanks commented Mar 10, 2024 • edited Loading

wshanks commented Mar 10, 2024

andrewgsavage Mar 10, 2024 • edited Loading

Choose a reason for hiding this comment

andrewgsavage Mar 10, 2024

Choose a reason for hiding this comment

wshanks Mar 10, 2024

Choose a reason for hiding this comment

jagerber48 Mar 10, 2024 • edited Loading

Choose a reason for hiding this comment

wshanks commented Mar 10, 2024

wshanks Mar 10, 2024 • edited Loading

Choose a reason for hiding this comment

jagerber48 commented Mar 10, 2024

newville commented Mar 11, 2024

wshanks commented Mar 11, 2024

codecov bot commented Mar 15, 2024 • edited Loading

Codecov Report

wshanks commented Mar 15, 2024

newville commented Mar 15, 2024

wshanks commented Mar 10, 2024 •

edited

Loading

andrewgsavage Mar 10, 2024 •

edited

Loading

jagerber48 Mar 10, 2024 •

edited

Loading

wshanks Mar 10, 2024 •

edited

Loading

codecov bot commented Mar 15, 2024 •

edited

Loading