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&replace easily. Having the name
verbatim in there makes the whole thing easier to read and copy&paste.
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
