New (optional) python egg dependency generator for RPM

[Nick Coghlan]

On 18 November 2015 at 02:29, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
>>>>>> "NC" == Nick Coghlan <ncoghlan at 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 at gmail.com   |   Brisbane, Australia