On Nov 16, 2017 4:59 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote:
On 16 November 2017 at 22:33, Miro Hrončok <mhron...@redhat.com> wrote: > Adding the link makes sense to me. Adding all the macros definition to the > wiki does not make sense to me, but form different reasons. I think that > having %py3_build_egg and %py3_install_egg there is just not necessary. > Since there are more files at [0] I'd just add that link. > > [0] https://src.fedoraproject.org/rpms/python-rpm-macros/tree/master Even though it's just a new informational link, I'm guessing we still need to file an FPC ticket for that? I think that macros we care about should be on that page, not just at that link. However, you should check with tibbs/FPC about whether the definitions/list of macros are an altogether dated concept. When I was there we used those because spec files are just shell scripts. For a sysadmin to become a packager, they just needed to understand a few concepts about the structure of the spec file but otherwise they just put their steps from the command line into the spec. Defining the macros on the page allowed those users to see how the macro replaced some steps of their manual procedure. However, that may no longer be the audience of the guidelines. It may be that they're now targeting programmers or packagers who don't have the same intimate relationship to the command line as sysadmin and have a greater comfort learning a domain specific language to do a job. In that case, perhaps the entire concept of enumerating the macros is unneeded for that target audience. Instead, simply introducing the macros when they're used in the guidelines is enough. Talk to tibbs/FPC about what their thoughts are. > * if so, should we add a new section of the guidelines? something like > "Packaging setup.py-less projects"? > Rather than emphasising the absence of setup.py, I'd emphasise the use of wheel files: * "Defining an RPM based on a wheel build process" * "Defining an RPM based on a setup.py file" I would not emphasize the use of wheel files as they are not source and from flit's documentation, it doesn't appear that wheels are even central to it (contrast how much wheel is mentioned in its documentation compared to pyproject.tom). Instead I would emphasize flit itself as the build tool which we're using to transform the source into the files on our systems. If there's ever an alternative to flit which builds with wheels as part of that process we'll need new guidelines based on that so using wheel as the prime keyword that people associate with this build process instead of flit is not future proof either. -Toshio
_______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
