search

valknight / Cohost.py

A python library for Cohost.org!
MIT License
58 stars 8 forks source link

Make packaging compliant with PEP 621, PEP 518 #16

Closed oliviacrain closed 2 years ago

oliviacrain commented 2 years ago

Summary

This PR brings Cohost.py's packaging metadata up to current, future-proof-ish standards by replacing setup.py with pyproject.toml.

PEP 518 deals with establishing a schema for the pyproject.toml file as a standard specification of build system requirements. PEP 621 deals with a format for specifying general packaging metadata in pyproject.toml. These documents reflect the current/future norms around packaging metadata.

Old functionality is dying, new functionality is taking hold, now is the time of relatively tame monsters.

The list of changes is a bit long- mostly for me to be sure I'm doing the right thing.

Changes

Move to a single declarative config in pyproject.toml to specify project metadata. We no longer need an executable setup.py file to set up our build, since setuptools is able to extract equivalent data from pyproject.toml.

The minimal setuptools version required to build from source is now 61.0.0 (released Mar 2022). This allows us to specify setuptools-specific metadata in pyproject.toml instead of in a separate setup.cfg file. This is a version bump from the previous unspecified minimum version. This isn't really an issue for most anyone- most if not all consumers are consuming the wheel from PyPI, not the source distribution, and won't need to invoke setuptools to build cohost.

Packaging metadata is now statically defined in pyproject.toml instead of being dynamically defined in cohost/__version__.py. If we determine that accessing package metadata from source code is necessary, then we can change the necessary attributes to be dynamically read from source. But as of now, I see no usage of this information that requires such a thing.

We no longer use python3 setup.py install in build.sh. This command has been deprecated since setuptools 58.3.0 (released Oct 2021). Instead, we use the build build frontend tool to read our build backend specification in pyproject.toml and invoke setuptools to build our source distribution and wheel. Again, this is only needed for the small number of people building cohost from source.

We remove the Pipfile and Pipfile.lock files. I may be wrong, but I see these files (and the pipenv tool that uses them) as more of a construct for installed/deployed applications. As a library,cohost doesn't want to overly specify dependencies and constrain package consumers. As developers, we don't really benefit from a shared base of dependencies being kept in a lockfile (and the maintenance burden it brings with it). Also, it doesn't seem like we use these files, judging by (a) the defined development dependencies that are unused and (b) the fact that we don't use pipenv in the build script. I'm guessing these files are a holdover from the repo template. If I'm wrong and you use it/see value in keeping it, then I'm more than happy to revert that change.

Tests

Used new version of build.sh with the existing example.py script to chost on my automation page. I figure this is a good way to ensure the current module structure was preserved through the change.

valknight commented 2 years ago

Thanks so much! This all looks great - merged in 😄