search

getsolus / ypkg

Modern, declarative, structured build format
https://getsol.us
GNU General Public License v3.0
22 stars 11 forks source link

Add new python macros to adjust to PEP 517/518 #23

Closed joebonrichie closed 2 years ago

joebonrichie commented 2 years ago

These macros should be used when a setup.py file is not present but a pyproject.toml/setup.cfg file is.

Setuptools PEP517 tested via python-jsonschema Poetry build system tested via yubikey-manager Flit build system tested via python-mediafile

kyrios123 commented 2 years ago

Why not testing adding a test to the existing macros to check if a setup.py doesn't exists and yproject.toml/setup.cfg exists ?

joebonrichie commented 2 years ago

I guess you're suggesting that the python3 macros should be expanded instead to something like:

if setup.py exists
   python3 setup.py ...
else if pyproject.toml exists
   python3 -m pip wheel ...
fi

I planned to edit common/Scripts/yauto.py to add the pyproject_{build,install} macros if a pyproject.toml file is found, it may be better to have the existing macro handle both as you've suggested though.

Just thinking out loud here:

If a project provides both a pyproject.toml file as well as a setup.py file we may want to force usage of one over the other. in case of build bugs. That may not be a real problem in practice though.

If we use the existing macros, we probably don't need to "isolate" the resulting build files anymore since we'll only be supporting python3 and there'll be no python2 files to contaminate the build.

I have no strong preference either way. Maybe worth checking what other people think.

joebonrichie commented 2 years ago

I adjusted the existing macros per suggestion https://github.com/joebonrichie/ypkg/commit/3b675ee39df37508465a42a28d0f5526d6708a8b

We'll need to decide whether to adjust the existing macros or use new macros.

JoshStrobl commented 2 years ago

If the intended direction in the Python community is to move towards using pyproject.toml / setup.cfg instead of setup.py, then it may be advantageous to introduce support in our existing macro for that build system to enable a smoother transition between the build systems.

If this is just "yet another build system" that is expected to just be adopted by a small subset of the Python community, it is probably not in our interest to complicate our existing macros with the support and keep it isolated to its own set of macros.

In terms of instances where there are "build bugs" that prevent the use of one over another, we already have instances of this with Meson and GNU Autotools, where some projects don't support standardized flags and treat any supplemental flags fatally, or have their own devilry with separate bootstrapping prior to using configure. In those cases, we break away from using our macros and use whatever commands are preferred by the upstream.

I look at these as temporary problems that typically end up resolving themselves over time, either by a new release from upstream, patches during packaging, or patches either pulled from proposed MRs or even those submitted by Solus community members. Going out of our way to complicate our own packaging for what would be an even smaller subset of an existing subset of developers (those shipping the new build system, but shipping its support broken) would just be silly.

joebonrichie commented 2 years ago

Closed in favour of https://github.com/getsolus/ypkg/pull/24