Re: Redesigning the %python_provide macro from scratch
On 28. 04. 20 11:35, Miro Hrončok wrote: %py_provides is actually much better: - shorter, yet still understandable - easily distinguishable from %python_provide Thanks. %py_provides is now available in rawhide for testing. I will backport it later, so for now using it unconditionalized might break srpm creations on older Fedoras. For that, you can create SRPMS in mock: $ mock -r fedora-rawhide-x86_64 --spec=xxx.spec --buildsrpm --sources=. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Rawhide python-rpm-generators news: small speedup + %python_provide not needed in most cases
On 08. 04. 20 13:28, Miro Hrončok wrote: On 07. 04. 20 12:27, Miro Hrončok wrote: When you use %python_provide and when you build the package with the new generator, the provides are listed twice: $ rpm -qp --provides python3-double-provides-0-0.fc33.noarch.rpm python-double-provides = 0-0.fc33 python-double-provides = 0-0.fc33 python3-double-provides = 0-0.fc33 python38-double-provides = 0-0.fc33 python38-double-provides = 0-0.fc33 $ rpmlint python3-double-provides-0-0.fc33.noarch.rpm ... python3-double-provides.noarch: E: useless-provides python-double-provides python3-double-provides.noarch: E: useless-provides python38-double-provides ... I've reported that as a bug in RPM: https://github.com/rpm-software-management/rpm/issues/1166 Apparently, there is a good reason to not have those merged. People are notified of the uselessness of the manual one. I'll take that into account when amending the guidelines. Good news is that I've managed to workaround the double-generated provide and even if you keep using %python_provide for backwards compatibility, you will now only get the provides once. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Newbie introduction to Python SIG
Hi guys, I was looking to join Fedora development, and as I'm most familiar with Python, I thought the Python SIG would be my way to go. Following the https://fedoraproject.org/wiki/SIGs/Python/JoinSIG guide, it suggests to post a self-introduction to the mailing list, so that's what I'm doing now :) I'm a student who started coding about 8 years ago with some basic Python book from the local library, got really into it and stopped again later. I then re-learnt a lot about 4 years ago and started building actual projects.My favourite projects include webservers (using quart or sanic), Discord Bots with discord.py (a great lib!) and parsers (though, I need to work on my knowledge there). I had my adventures into Rust and am pretty solid at JS. A few weeks ago I submitted my first PR into CPython (yay!). I am looking to help in any way possible to bring Fedora and especially Python in Fedora forward. I'm a noob when it comes to mailing lists and stuff - I hope people have patience with me. I'm @Gelbpunkt in IRC and will try to hang out in the fedora-python channel as often as I can. I would apprechiate getting some starting tips in where to contribute and in which way help would be needed. I've looked at the list of starting points - porting Python 2 to 3 seems where I feel most comfortable - though, starting tips would be apprechiated! If required, I'll be willing to dive into cold water ;) Many greetings from Germany,Jens aka adriany___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Draft of New Python Packaging Guidelines
On 2020-04-30 15:41, Petr Viktorin wrote:
Hello!
Below is a draft of new Packaging Guidelines! It's full of unfinished
areas (marked with XXX), but it's ready for scrutiny.
A possibly updated version is on
https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg?view
[...]
The draft lives on hackmd.io, which we found easy to collaborate with.
If you have an account there, we can add you. If you'd like to
collaborate some other way, let us know.
There were some comments on the hackmd pad, which might be more visible
in e-mail, so I'll quote & answer them here.
They seem like details, though. Do the overall ideas look good?
One comment was about the "Dots in package names" comment. That's in
progress; see the mail from Tomáš about renaming `python39` to
`python3.9`:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/
### Canonical project name
Most of these names are case-sensitive machine-friendly identifiers, but
the *project name* has human-friendly semantics: it is case-insensitive
and treats some sets of characters (like `._-`) specially.
For automated use, it needs to be
[normalized](https://www.python.org/dev/peps/pep-0503/#normalized-names)
to a canonical format used by Python tools and services such as
setuptools, pip and PyPI.
The `%{py_dist_name}` macro implements this normalization.
Elsewhere in this text, the metavariable `DISTNAME` refers to the
canonical form of the project name.
> XXX
> ```spec
> # XXX specfile
> %py_set_name Django
> -> %distname django
> -> %pojectname Django
> ```
This is quite a cryptic note, but the idea is that you'd do
`%py_set_name Django`, and %distname & %projectname would get defined
for you, so that you can use them in the rest of the spec file.
Zbyszek said:
Please don't advertise macros like %distname, %srcname, %origname, and
the countless other variants in use. They made sense when people used > editors
which didn't support search easily. Having the name
verbatim in there makes the whole thing easier to read and copy
The idea was to standardize these, so we'd get well known names instead
of each packager defining their own. Then, macros like %pypi_url could
use the well-known name by default. This would also take care of the
subtle differences between names: in Django's case, you need to use
capital D in the URL, but automatic provides use the canonicalized
lowercase. Even search/replace is likely to miss these (but, inevitably
packagers themselves will also be confused :/)
It's definitely possible to get rid of %py_set_name, and deprecate
%pypi_url's weird default -- you'd be expected to write out `%pypi_url
Django` every time.
I'm not sure if that would prevent people from using
%distname/%srcname/%origname/%pypiname, but it looks like the right
thing to do.
### Machine-readable provides
Every Python package **MUST** provide `python3dist(DISTNAME)` **and**
`python3.Xdist(DISTNAME)`, where `X` is the minor version of the
interpreter and `DISTNAME` is the *canonical project name* corresponding
to the *dist-info metadata*, for example `python3.9dist(requests)`.
(XXX: add links to previous sections)
This is generated automatically from the dist-info metadata.
The provide **SHOULD NOT** be added manually: if the generator fails to
add it, the metadata **MUST** be fixed.
If necessary, the automatic generator can be disabled by undefining
`%__pythondist_provides`.
Neal writes:
There should be absolutely _no_ circumstance where the Provides
generator needs to be completely disabled. What cases were you
thinking about that might require this?
IMO, when there is automation, you should be able to disable it. It's
for the cases I *don't* know about.
But I'll update to some stronger language.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
