Dear python-devel list,
I have few questions about the Packaging:Python wikipage[1], with hope that this list is the right one for me to do so.
The page doesn't discuss much any differences in guidelines for packages of python modules, python applications and when python project provides both. For example both ruby and haskell packaging guidelines covers this topic. Would you consider this to be important/useful enough for new packager to provide better guidance?
There is no mention of any semi automatic tools which would try to create initial spec file based on metadata provided in PyPI. Like bdist_rpm of distutils or py2pack. Do you use them to create initial spec file? Is there any official policy on this? Is there any reason not to use such tools?
Moreover would you think that listing few nicely packaged python projects on the wikipage would make sense?
Besides that I puzzled about few other details which involves "python 3 as default" requirements, but this I leave out for now.
[1] https://fedoraproject.org/wiki/Packaging:Python
Thank you for your answer
Martin Bukatovic
"MB" == Martin Bukatovič martin.bukatovic@gmail.com writes:
MB> The page doesn't discuss much any differences in guidelines for MB> packages of python modules, python applications and when python MB> project provides both.
It shouldn't really need to; the question isn't specific to python at all.
MB> Would you consider this to be important/useful enough for new MB> packager to provide better guidance?
Perhaps a section in the main guidelines would be warranted. For some reason I already thought it was there, but I don't see it while searching. I'll see if I can draft something.
MB> Moreover would you think that listing few nicely packaged python MB> projects on the wikipage would make sense?
That definitely doesn't belong in a packaging guideline.
- J<
On 10 June 2015 at 08:41, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"MB" == Martin Bukatovič martin.bukatovic@gmail.com writes:
MB> The page doesn't discuss much any differences in guidelines for MB> packages of python modules, python applications and when python MB> project provides both.
It shouldn't really need to; the question isn't specific to python at all.
MB> Would you consider this to be important/useful enough for new MB> packager to provide better guidance?
Perhaps a section in the main guidelines would be warranted. For some reason I already thought it was there, but I don't see it while searching. I'll see if I can draft something.
MB> Moreover would you think that listing few nicely packaged python MB> projects on the wikipage would make sense?
That definitely doesn't belong in a packaging guideline.
I agree it doesn't make sense to include that information in the Python packaging guidelines, but I think it does make sense to provide such recommendations *somewhere*. We know cargo culting is inevitable, so it at least makes sense to have a way for folks to find *good* examples, rather than having them pick at random.
Along those lines, it would potentially be useful to have a Python specific packaging *tutorial* on the wiki an an alternative to the generic https://fedoraproject.org/wiki/How_to_create_an_RPM_package that assumes folks will be doing everything by hand.
For Python, it would make more sense to start with a tool like Slavek's pyp2rpm to generate the initial SPEC file: https://pypi.python.org/pypi/pyp2rpm
That will deal with a lot of basic aspects, and let packagers focus on the delta between what pyp2rpm generates and what they need. As work on the upstream Python metadata 2.0 spec proceeeds, we'll hopefully be able to get that delta down to making changes to their *Python* level metadata, and have the conversion to a policy compliant RPM be fully automated in the vast majority of cases.
Such a page could also be linked from https://packaging.python.org/en/latest/deployment.html#os-packaging-installe..., providing a clearer entry point for Pythonistas already familiar with Python's packaging tools into the RPM ecosystem.
Cheers, Nick.
"NC" == Nick Coghlan ncoghlan@gmail.com writes:
NC> I agree it doesn't make sense to include that information in the NC> Python packaging guidelines, but I think it does make sense to NC> provide such recommendations *somewhere*.
I obviously agree, given that I wrote that I would try and draft something. Just haven't had much time yet.
NC> Along those lines, it would potentially be useful to have a Python NC> specific packaging *tutorial* on the wiki an an alternative to the NC> generic https://fedoraproject.org/wiki/How_to_create_an_RPM_package NC> that assumes folks will be doing everything by hand.
That's certainly not a bad idea. It's a wiki; feel free to run with it.
NC> For Python, it would make more sense to start with a tool like NC> Slavek's pyp2rpm to generate the initial SPEC file: NC> https://pypi.python.org/pypi/pyp2rpm
The problem with doing any of this now is that the python guidelines are in significant flux and will hopefully emerge in a much cleaner state with various convenience macros to handle the bulk of the heavy lifting.
- J<
On 11 June 2015 at 14:05, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"NC" == Nick Coghlan ncoghlan@gmail.com writes:
NC> I agree it doesn't make sense to include that information in the NC> Python packaging guidelines, but I think it does make sense to NC> provide such recommendations *somewhere*.
I obviously agree, given that I wrote that I would try and draft something. Just haven't had much time yet.
Ah, my apologies - I missed that sentence when I read your reply.
NC> Along those lines, it would potentially be useful to have a Python NC> specific packaging *tutorial* on the wiki an an alternative to the NC> generic https://fedoraproject.org/wiki/How_to_create_an_RPM_package NC> that assumes folks will be doing everything by hand.
That's certainly not a bad idea. It's a wiki; feel free to run with it.
My own packaging experience is limited enough that I don't consider myself qualified to provide advice on how best to go about it - my involvement in Fedora's Python policy development has been from an upstream perspective rather than a Fedora perspective.
NC> For Python, it would make more sense to start with a tool like NC> Slavek's pyp2rpm to generate the initial SPEC file: NC> https://pypi.python.org/pypi/pyp2rpm
The problem with doing any of this now is that the python guidelines are in significant flux and will hopefully emerge in a much cleaner state with various convenience macros to handle the bulk of the heavy lifting.
Yeah, that makes sense. Once it settles down again and pyp2rpm can be updated accordingly, then a simpler getting started guide will be easier to write and maintain.
Cheers, Nick.
On 11 June 2015 at 14:38, Nick Coghlan ncoghlan@gmail.com wrote:
My own packaging experience is limited enough that I don't consider
Heh, that's specifically *Fedora* packaging experience. Software packaging and distribution in general is a very different story :)
Cheers, Nick.
On 06/11/2015 05:25 AM, Nick Coghlan wrote:
Along those lines, it would potentially be useful to have a Python specific packaging *tutorial* on the wiki an an alternative to the generic https://fedoraproject.org/wiki/How_to_create_an_RPM_package that assumes folks will be doing everything by hand.
Yes, having some quick start howto for Python (besides the guideline) would be really useful. It doesn't have to go deep into details.
For Python, it would make more sense to start with a tool like Slavek's pyp2rpm to generate the initial SPEC file: https://pypi.python.org/pypi/pyp2rpm
Thank you for pointer to this tool. I missed it when searching for specfile generators.
So that's something I had in mind when asking: which tool is suggested to be used to create initial specfile? what needs to be tweaked and how? And so on - which on the one hand obviously doesn't belong to the packaging guideline, but guidelines of some other languages (originally mentioned haskell or ruby) did include some note and guidance about it so I was a bit confused what does that mean for python packaging.
That will deal with a lot of basic aspects, and let packagers focus on the delta between what pyp2rpm generates and what they need. As work on the upstream Python metadata 2.0 spec proceeeds, we'll hopefully be able to get that delta down to making changes to their *Python* level metadata, and have the conversion to a policy compliant RPM be fully automated in the vast majority of cases.
Such a page could also be linked from https://packaging.python.org/en/latest/deployment.html#os-packaging-installe..., providing a clearer entry point for Pythonistas already familiar with Python's packaging tools into the RPM ecosystem.
python-devel@lists.fedoraproject.org
-
Jason L Tibbitts III -
Martin Bukatovic -
Nick Coghlan