Deprecate EOL version and centralize information about it

[lioman]

• I have searched the issues (including closed ones) and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.
• I am willing to lend a hand to help implement this feature.

Feature Request

As a pelican developer I just want to support current Python versions, so that I have not to test and cover more versions than necessary.
As a pelican user I want to have a quick way to understand, which versions are actually supported.

Description

In PR #3197 there was the proposal to ditch 3.7 as it is EOL. This. Issue tries to achieve the same but also centralize the information about supported versions. Currently, it seems that the version is mentioned at least in these locations:

• setup.py
• pyproject.toml
• docs/contribute.rst
• docs/install.rst
• docs/quickstart.rst

Proposal

use pyproject.toml as the single place to define that information and link it in other places (or ditch them if not needed anymore).

[lioman]

I'm willing to implement this, just opened it as a place for discussion

[pauloxnet]

+1 for me

[lioman]

My first open point for discussion:
We can either use poetry for building the package or just use setuptools and modernize it by using pyproject.toml to configure it. I have experience with both and both work. Are there any opinions about it?

[pauloxnet]

I usually prefer the KISS approach and use setuptools but I'd ask @justinmayer about this point.

[lioman]

About the KISS approach: I'm not sure what is the simplest thing.

1. using the old tool (setuptools) and transferring it to pyproject.toml
2. using one tool (poetry)

[justinmayer]

The Python packaging landscape has changed a lot over the last few years. I adopted Poetry rather early in its lifecycle and appreciated how it handled many of the more tedious aspects of Python dependency management and package release publication. Recently, however, I have come to realize that (1) Poetry tries to do too much, and (2) Poetry's path has diverged from the rest of the Python packaging community. The most notable example of the latter is Poetry's pre-existing idiosyncratic syntax in pyproject.toml, which is different from how the Python community has decided to handle things, such as declaring project metadata. According to a tweet by Poetry's author, Poetry will probably support these standards eventually, but I'd rather use tools that support those standards now. For the above reasons, I am not inclined to use Poetry going forward.

Ergo, I have started to experiment with tools that are designed to support PEP 631, which has since been merged into PEP 621, which is now codified in the above-linked PyPA project metadata specification. I have been experimenting with Hatchling as the build backend and PDM for dependency management. You can see an example of this combination in the Featured Image plugin repo and its pyproject file.

So, I think there are two choices to make here:

1. Which build backend do we want to use?
2. How do we want to handle dependency management?

In the end, other than wanting to choose standards-compliant tooling, I am open-minded regarding both choices. My initial impressions about our options:

1. Build backend: Hatchling or Setuptools
2. Dependency management: PDM or Hatch

Hatch requires using Hatchling as the build backend, while PDM is backend-agnostic and can be used with either Hatchling or Setuptools.

So from my perspective, I suppose the choices come down to:

• Hatchling + PDM (e.g., pyproject file from Featured Image plugin)
• Hatchling + Hatch (e.g., pyproject file from Structlog)
• Setuptools + PDM

Of course, those are just my impressions based on my experiences so far. If there are other choices we should consider, by all means please share your thoughts. What does everything think?

[lioman]

I just researched a bit ( and it was quite a rabbit hole).
It does make sense to use a PEP621 compatible format.
So poetry is a non fit here ( basically I have a quite similar story as you @justinmayer )

For some reason I would not choose setuptools, which is not super objective and more based on a feeling.

Hatch and pdm seem to be capable and I'm currently not sure what is the better tool.

Hatch is lacking basic management commands , like add or update

So currently I would probably lean towards pdm as a dependency management tool. And as build backend either the native one or flit as it only does exactly that.

I will first work on the metadata etc
If there are no new comments till then I will first start with a pdm based proposal.

[offbyone]

I would lean towards PDM as the dependency management tool, with hatchling as a possible build system.

[justinmayer]

I just learned that PDM can import configuration from other package management tools (such as Poetry), which could save a lot of time and effort. Very cool. 👍

[lioman]

Yeah, that was super helpful. I should push my current branch. The only thing left is adding the correct files to the build. But config wise it was 5 min of work.

[justinmayer]

@lioman: Could you push your current branch so we can collaborate on it? I would like to merge #3119, but that depends on dropping Python 3.7 first.

[offbyone]

I'm curious where it's at, too; I'm going to bed soonish, but I usually get up pretty early in the morning.

[lioman]

Will push it in an hour or so.

[lioman]

Pushed the Branch @justinmayer I'm away for the next ~7h will proceed working on that, depending on what is left to do.

Todo

• adapt documentation to read pyproject.toml
• check if files to build are added (transfer Manifest.in config)
• double check entry points. etc from setup.py
• remove setup.py

[justinmayer]

Many thanks, @lioman. I will take a look, and the results of that review will be waiting for you when you return. 😊