On Thu, Nov 10, 2016 at 7:49 AM, jan matejek <jmatejek@suse.com> wrote:
Hello, in relation to the python single-spec initiative, I have designed a set of new macros that allow significant automation in building Python packages.
However, these are constrained by the %python_module macro used in BuildRequires. The purpose of this macro is to expand %{python_module foo} to python2-foo, python3-foo, etc., based on which python flavors are build targets for the package. Obviously, the buildservice itself must be able to do this expansion, otherwise it can't resolve the build requirements.
So far I have solved this by placing all the macros in prjconf. But this is not viable if I want my macros to be available everywhere. I can create a "python-macros" package for all the other macros, and buildrequire it, in order to make the packages build in any distro that has this package, but I can't do the same for %python_module.
Is it possible to make the buildservice itself recognize this macro, or place it in some sort of global prjconf? Ideally without triggering a full rebuild of everything? Or do you have any tips for alternate solutions?
One thing that occured to me, instead of relying on macros, turn "python-foo" packages into metapackages requiring the respective "python2-foo", "python3-foo" etc., and then BuildRequire the metapackage. I don't have a clear idea about how well this would work, it seems rather problematic.
I don't want to make packagers list the buildrequires by hand, because the requirements can be numerous and we also want to be able to add more python flavors and expand the build requirements accordingly.
thanks for any tips m.
Why not pull in the dependency generator I upstreamed into RPM[1] into openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and Mageia is using an earlier variant of it now. It establishes common names for Python packages that provide egg-info or dist-info data (egg/wheel metadata installed on the system) that can be used for standardizing how Python dependencies are referenced. Fedora is currently only using it for Provides generation at the moment, but Mageia uses it for Provides and Requires generation. That would make it less onerous in general to package Python stuff, as it would gain useful dependency generation like Perl and Ruby have. Tools like pyp2rpm[4] can use these names for generating good spec files that can build packages properly. Petr Viktorin gave a presentation at Flock 2016[5][6] about the future of Python packaging in Fedora, with this as a key staple. [1]: https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondis... [2]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/ [3]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje... [4]: https://github.com/fedora-python/pyp2rpm [5]: https://speakerdeck.com/encukou/python-packaging-in-fedora [6]: https://www.youtube.com/watch?v=rp5jq-25nZg -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org