https://bugzilla.redhat.com/show_bug.cgi?id=2250532
--- Comment #9 from Ben Beasley <[email protected]> --- (In reply to Sandro from comment #8) > I'm not quite sure I fully understand your point here. Maybe that's because > I'm used to specifying dependencies as `python3-foo`, in which case it > doesn't matter if the package is a meta package or an actual Python package. > For Python packages that do provide importable modules, is there a > difference in specifying them as `python3-foo` or as `%{py3_dist foo}`. If > not, then that would be reason enough for me to standardize on the > `python3-foo` notation. Of course, if your preference is with `%{py3_dist > foo}`, you end up having to mix both as in the case of > `python3-sphinx-latex`. I think the best reason for using either python3dist(foo) or %{py3_dist foo} rather than python3-foo is that the first two forms express the dependency on the machine-readable Provides[1], which are based on the project canonical name and should be more stable than relying on the name of the subpackage that offers those Provides. As far as I know, all three forms are permissible. I think the best reason for using %{py3_dist foo} over python3dist(foo) is that the macro normalizes names; for example, %{py3_dist Foo_Bar} produces python3dist(foo-bar). Now, there’s nothing wrong with writing python3dist(foo-bar) directly, but when you’re maintaining manual lists of BuildRequires by copying them out of some requirements.txt file that pins dependency versions and is full of linters and coverage tools, or out of a [tool.poetry.dev-dependencies] table that does the same *and* you can’t generate BR’s from it directly anyway, it’s nice to be able to just copy what you see rather than always thinking about whether and how you need to normalize names. That doesn’t come into play in this package, but I’ve gradually settled on using %{py3_dist foo} everywhere for this reason. And my washing machine has been behaving suspiciously, so I’ll be sure to comb through the fine print of your points program for loopholes. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2250532 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202250532%23c9 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
