On 2017-08-25 14:00:25 +0100 (+0100), Paul Moore wrote: [...] > I'm not that familiar with those tools, but if they enable that > sort of use then that's great. I did get the impression that they > were for more complex/specialised use cases, though, whereas flit > (with PEP 517) is much more about simple configuration for the > majority of (pure Python) projects that don't need complex > behaviour. [...]
Not really, no; pretty much everything in OpenStack is pure Python
as well and relies on PBR. I can't personally think of any non-pure
package I've seen using PBR, so it may not even be usable outside
pure Python packaging for all I know (I've certainly never tried
anyway).
PBR basically started with the primary goals of reducing copied code
by simplifying common setup.py file patterns and integrating
features to help avoid additional setup_requires which couldn't
easily be versioned (especially back in those days) without causing
all manner of breakage when they might end up conflicting with
transitive install_requires. With PEP 517 on the way now I consider
these earlier attempts at declarative package definitions will be
more of a historical footnote soon enough, but the intent was pretty
similar. Here's an example setup.cfg from a reasonably simple
command-line utility:
https://git.openstack.org/cgit/openstack-infra/bindep/tree/setup.cfg
Anyway, my point wasn't to advertise these tools specifically, but
rather to point out that there's nothing stopping projects who want
to extract their package metadata into static configuration and
bundle their setuptools logic into a separate reusable module (for
example by leveraging a setuptools entrypoint the way PBR does)
without having to wait around for PEP 517. Then they can always
revisit the design once PEP 517 support is more generally rolled out
in standard packaging tools.
> One thought - are the PBR and/or distutils2 teams looking at
> providing PEP 517 support? Assuming they are, have they had a
> change to review the PEP to ensure it suits their needs? And if
> they aren't, what is it about the PEP that makes them unwilling to
> do so?
As far as I know, Distutils2 has essentially been dead upstream for
~5 years, so I wouldn't expect it to receive any updates in that
regard.
I've had conversations with the primary maintainers of PBR about
what would need to be done to coexist with and eventually take
advantage of PEP 517 paradigms. On-the-fly generation of
pyproject.toml files during or, if necessary, preceding the sdist
build phase is probably the way they'll be looking to go there,
though the details have yet to be completely hashed out. (The
community around it is sensitive to gender diversity issues and
wants to avoid acquiring more of a "brogrammer" image, so some of us
worry that any conspicuous TOML files checked into revision control
repositories could be seen as a tacit endorsement of the author's
alleged behavior at GH a few years ago.)
--
Jeremy Stanley
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
