On 18 November 2015 at 02:29, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "NC" == Nick Coghlan
<ncoghlan(a)gmail.com> writes:
NC> If so, then there's some relevant work currently under way upstream
NC> to improve the interaction between Python installation tools and
NC> build systems to improve the metadata extraction process, rather
NC> than relying on implementation details of setuptools.
If that's the case, could someone bang out a few paragraphs that we
could use as a blueprint for some packaging guidelines? An example
spec, or even just the file layout and some idea of how autogenerated
dependencies would work would be enough. I know this stuff is a bit
new, but we've been doing a really big overhaul of the python stuff and
we'd like to at least design to accommodate this rather than having to
do it all over again once this new format comes out.
The main policy changes would be to update these two section to
mention keeping dist-info directories:
*
https://fedoraproject.org/wiki/Packaging:Python#Files_to_include
*
https://fedoraproject.org/wiki/Packaging:Python#Reviewer_checklist
It would also be desirable to state a preference for dist-info over egg-info.
Thinking about it a bit further, I don't think the latest round of
upstream changes should impact the metadata analysis step, as the
metadata querying changes are designed to support getting at the
metadata without building and installing the package first, and that's
not a consideration for the RPM use case.
However, they could potentially affect the py2/3_build macros, as
we're looking to finally migrate away from *requiring* the presence of
a setup.py file in every source tree, and instead allow out-of-tree
build tools, with machine readable instructions for bootstrapping them
into the build environment.
The draft PEP for that is at
https://github.com/pypa/interoperability-peps/pull/54/files and
upstream discussions are on distutils-sig
I'd been thinking using "pip install" instead of "setup.py
install" in
the build macros would be sufficient, but I now realise that isn't the
case - if a project uses flit (for example) as its build utility, then
we're going to need to generate a suitable BuildRequires in pyp2rpm
and similar tools (perhaps using the "BuidlRequires:
pythonX.Ydist(flit)" format). The build macros themselves could still
delegate the task of working out the right build command to invoke to
pip, though.
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia