Re: Draft of New Python Packaging Guidelines - 0.2

[Neal Gompa]

On Wed, Aug 12, 2020 at 12:02 PM Petr Viktorin  wrote:
>
> On 2020-08-12 17:22, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:
> >>
> >> On 2020-08-12 16:53, Neal Gompa wrote:
> >>> On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  
> >>> wrote:
> 
>  I'll move some discussion here, where it doesn't become part of the
>  document:
> 
> >
> > On 2020-08-11 14:19, Petr Viktorin wrote:
> >> These Guidelines represent a major rewrite and paradigm shift, and not
> >> all packages are updated to reflect this.
> >> Older guidelines are still being kept up to date, and existing packages
> >> **MAY** use them instead of this document:
> >> * 201x-era [Python packaging
> >> guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
> >> (for packages that use e.g. `%py3_install` or `setup.py install`)
> >> * [Python 2
> >> appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
> >> (for e.g. `%py2_install`) (Python 2 packages require a FESCo 
> >> exception.)
> 
>  @Conan-Kudo:
> > Is there something you've done here to make the new macros 
> > unequivocally better? Do you have automated flavor builds, for example? 
> > Right now there is no effective difference.
> 
> 
>  The new macros allow other build tools than just setuptools.
>  They also use upstream metadata for BuildRequires & file lists.
> 
>  Of course, where possible the changes were backported to the existing
>  macros. I don't necessarily see the macros as the main thing that
>  changes. But when you look at a specfile, you can usually tell what
>  conventions it uses by what macros you see.
> 
> >>>
> >>> Those are all nice things, for sure. I think it'd be important to
> >>> spell that out somewhere.
> >>
> >> Do you mean providing a summary of the changes between the existing
> >> guidelines and these?
> >>
> >
> > Yes. Also indicating the *why* for pyproject stuff is useful within
> > the context of why the old macros are deprecated.
>
> Is that necessary for the beta release of the packaging guidelines?
> (i.e. when they would be in effect, but optional?)
>
> You're asking for quite a lot of work around describing a document that
> might still change.
>
>

I am only asking for what makes sense if the document as it stands
were to be finalized.

> >> ## PyPI parity
> >>
> >> Every Python package in Fedora **SHOULD** also be available
> >> on [the Python Package Index](https://pypi.org) (PyPI).
> >>
> >> The command `pip install PROJECTNAME` **MUST** install the same package
> >> (possibly in a different version),
> >> install nothing,
> >> or fail with a reasonable error message.
> >>
> >> If this is not the case, the packager **MUST** contact upstream about 
> >> this.
> >> The goal is to get the project name registered or blocked on PyPI,
> >> or to otherwise ensure the rule is followed.
> >>
> >> To block a project name on PyPI, email
> >> [ad...@pypi.org](mailto:ad...@pypi.org),
> >> giving the project name and explaining the situation
> >> (for example: the package cannot currently be installed via `pip`).
> >> You can ask questions and discuss the process at the [Python
> >> Discourse](https://discuss.python.org/t/block-names/4045).
> >>
> >>> NOTE: Project names that were in Fedora but not on PyPI
> >>> when these guidelines were proposed
> >>> are *blocked* from being uploaded to PyPI.
> >>> This prevents potential trolls from taking them,
> >>> but it also blocks legitimate owners.
> >>> If your package is affected, contact the Python SIG
> >>> or [file a PyPA
> >> issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME)
> >>
> >>> and mention `@encukou`.
> >>
> >> This is necessary to protect users,
> >> avoid confusion,
> >> and enable automation as Fedora and upstream ecosystems grow more
> >> integrated.
> >>
> >> As always, [specific exceptions can be granted by the Packaging
> >> Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).
> 
> 
>  @Conan-Kudo:
> > This is not reasonable to ask of packagers to do. Such a check is 
> > difficult to do, and there is no particularly compelling reason for 
> > making everything written in Python using Python build system available 
> > in PyPI. Unless you plan to provide an automated system to inform PyPI 
> > of these things, this is not only unreasonable, it is unenforceable.
> 
>  A lot of stuff in the guidelines is unenforceable, so let's focus on the
>  "unreasonable" part.
> 
>  There is no reason to have e

Re: Draft of New Python Packaging Guidelines - 0.2

[Petr Viktorin]

On 2020-08-12 17:22, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:


On 2020-08-12 16:53, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:


I'll move some discussion here, where it doesn't become part of the
document:



On 2020-08-11 14:19, Petr Viktorin wrote:

These Guidelines represent a major rewrite and paradigm shift, and not
all packages are updated to reflect this.
Older guidelines are still being kept up to date, and existing packages
**MAY** use them instead of this document:
* 201x-era [Python packaging
guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
(for packages that use e.g. `%py3_install` or `setup.py install`)
* [Python 2
appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
(for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)


@Conan-Kudo:

Is there something you've done here to make the new macros unequivocally 
better? Do you have automated flavor builds, for example? Right now there is no 
effective difference.



The new macros allow other build tools than just setuptools.
They also use upstream metadata for BuildRequires & file lists.

Of course, where possible the changes were backported to the existing
macros. I don't necessarily see the macros as the main thing that
changes. But when you look at a specfile, you can usually tell what
conventions it uses by what macros you see.



Those are all nice things, for sure. I think it'd be important to
spell that out somewhere.


Do you mean providing a summary of the changes between the existing
guidelines and these?



Yes. Also indicating the *why* for pyproject stuff is useful within
the context of why the old macros are deprecated.


Is that necessary for the beta release of the packaging guidelines? 
(i.e. when they would be in effect, but optional?)


You're asking for quite a lot of work around describing a document that 
might still change.




## PyPI parity

Every Python package in Fedora **SHOULD** also be available
on [the Python Package Index](https://pypi.org) (PyPI).

The command `pip install PROJECTNAME` **MUST** install the same package
(possibly in a different version),
install nothing,
or fail with a reasonable error message.

If this is not the case, the packager **MUST** contact upstream about this.
The goal is to get the project name registered or blocked on PyPI,
or to otherwise ensure the rule is followed.

To block a project name on PyPI, email
[ad...@pypi.org](mailto:ad...@pypi.org),
giving the project name and explaining the situation
(for example: the package cannot currently be installed via `pip`).
You can ask questions and discuss the process at the [Python
Discourse](https://discuss.python.org/t/block-names/4045).

   > NOTE: Project names that were in Fedora but not on PyPI
   > when these guidelines were proposed
   > are *blocked* from being uploaded to PyPI.
   > This prevents potential trolls from taking them,
   > but it also blocks legitimate owners.
   > If your package is affected, contact the Python SIG
   > or [file a PyPA
issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME)

   > and mention `@encukou`.

This is necessary to protect users,
avoid confusion,
and enable automation as Fedora and upstream ecosystems grow more
integrated.

As always, [specific exceptions can be granted by the Packaging
Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).



@Conan-Kudo:

This is not reasonable to ask of packagers to do. Such a check is difficult to 
do, and there is no particularly compelling reason for making everything 
written in Python using Python build system available in PyPI. Unless you plan 
to provide an automated system to inform PyPI of these things, this is not only 
unreasonable, it is unenforceable.


A lot of stuff in the guidelines is unenforceable, so let's focus on the
"unreasonable" part.

There is no reason to have everything available on PyPI, but I do
believe it's reasonable to *reserve the name* in such cases.

Here's a reason why I want this:

The issue here is that Python tools have access to project names. For
example, I can get the version of Requests using:

   >>> from importlib.metadata import version
   >>> version('requests')
'2.22.0'

Things like this are only useful if we use a common namespace. Upstream,
that namespace *is* PyPI; there's little we can do about that.
If project names mean something else in Fedora than in the wider
ecosystem, we'll get user confusion at best.

(If you use a private package index, like they do at CERN or some
closed-source shops, there can be some collisions -- but in that case
there's a limited number of software authors and users, and a lot more
control over the package set. Conflicts in global repositories of
free/open-source software are much harder t

Re: Draft of New Python Packaging Guidelines - 0.2

[Neal Gompa]

On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:
>
> On 2020-08-12 16:53, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:
> >>
> >> I'll move some discussion here, where it doesn't become part of the
> >> document:
> >>
> >>>
> >>> On 2020-08-11 14:19, Petr Viktorin wrote:
>  These Guidelines represent a major rewrite and paradigm shift, and not
>  all packages are updated to reflect this.
>  Older guidelines are still being kept up to date, and existing packages
>  **MAY** use them instead of this document:
>  * 201x-era [Python packaging
>  guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
>  (for packages that use e.g. `%py3_install` or `setup.py install`)
>  * [Python 2
>  appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
>  (for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)
> >>
> >> @Conan-Kudo:
> >>> Is there something you've done here to make the new macros unequivocally 
> >>> better? Do you have automated flavor builds, for example? Right now there 
> >>> is no effective difference.
> >>
> >>
> >> The new macros allow other build tools than just setuptools.
> >> They also use upstream metadata for BuildRequires & file lists.
> >>
> >> Of course, where possible the changes were backported to the existing
> >> macros. I don't necessarily see the macros as the main thing that
> >> changes. But when you look at a specfile, you can usually tell what
> >> conventions it uses by what macros you see.
> >>
> >
> > Those are all nice things, for sure. I think it'd be important to
> > spell that out somewhere.
>
> Do you mean providing a summary of the changes between the existing
> guidelines and these?
>

Yes. Also indicating the *why* for pyproject stuff is useful within
the context of why the old macros are deprecated.

>  ## PyPI parity
> 
>  Every Python package in Fedora **SHOULD** also be available
>  on [the Python Package Index](https://pypi.org) (PyPI).
> 
>  The command `pip install PROJECTNAME` **MUST** install the same package
>  (possibly in a different version),
>  install nothing,
>  or fail with a reasonable error message.
> 
>  If this is not the case, the packager **MUST** contact upstream about 
>  this.
>  The goal is to get the project name registered or blocked on PyPI,
>  or to otherwise ensure the rule is followed.
> 
>  To block a project name on PyPI, email
>  [ad...@pypi.org](mailto:ad...@pypi.org),
>  giving the project name and explaining the situation
>  (for example: the package cannot currently be installed via `pip`).
>  You can ask questions and discuss the process at the [Python
>  Discourse](https://discuss.python.org/t/block-names/4045).
> 
>    > NOTE: Project names that were in Fedora but not on PyPI
>    > when these guidelines were proposed
>    > are *blocked* from being uploaded to PyPI.
>    > This prevents potential trolls from taking them,
>    > but it also blocks legitimate owners.
>    > If your package is affected, contact the Python SIG
>    > or [file a PyPA
>  issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME)
> 
>    > and mention `@encukou`.
> 
>  This is necessary to protect users,
>  avoid confusion,
>  and enable automation as Fedora and upstream ecosystems grow more
>  integrated.
> 
>  As always, [specific exceptions can be granted by the Packaging
>  Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).
> >>
> >>
> >> @Conan-Kudo:
> >>> This is not reasonable to ask of packagers to do. Such a check is 
> >>> difficult to do, and there is no particularly compelling reason for 
> >>> making everything written in Python using Python build system available 
> >>> in PyPI. Unless you plan to provide an automated system to inform PyPI of 
> >>> these things, this is not only unreasonable, it is unenforceable.
> >>
> >> A lot of stuff in the guidelines is unenforceable, so let's focus on the
> >> "unreasonable" part.
> >>
> >> There is no reason to have everything available on PyPI, but I do
> >> believe it's reasonable to *reserve the name* in such cases.
> >>
> >> Here's a reason why I want this:
> >>
> >> The issue here is that Python tools have access to project names. For
> >> example, I can get the version of Requests using:
> >>
> >>   >>> from importlib.metadata import version
> >>   >>> version('requests')
> >> '2.22.0'
> >>
> >> Things like this are only useful if we use a common namespace. Upstream,
> >> that namespace *is* PyPI; there's little we can do about that.
> >> If project names mean something else in Fedora than in the wider
> >> ecosystem, we'll get user confusion at be

Re: Draft of New Python Packaging Guidelines - 0.2

[Petr Viktorin]

On 2020-08-12 16:53, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:


I'll move some discussion here, where it doesn't become part of the
document:



On 2020-08-11 14:19, Petr Viktorin wrote:

These Guidelines represent a major rewrite and paradigm shift, and not
all packages are updated to reflect this.
Older guidelines are still being kept up to date, and existing packages
**MAY** use them instead of this document:
* 201x-era [Python packaging
guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
(for packages that use e.g. `%py3_install` or `setup.py install`)
* [Python 2
appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
(for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)


@Conan-Kudo:

Is there something you've done here to make the new macros unequivocally 
better? Do you have automated flavor builds, for example? Right now there is no 
effective difference.



The new macros allow other build tools than just setuptools.
They also use upstream metadata for BuildRequires & file lists.

Of course, where possible the changes were backported to the existing
macros. I don't necessarily see the macros as the main thing that
changes. But when you look at a specfile, you can usually tell what
conventions it uses by what macros you see.



Those are all nice things, for sure. I think it'd be important to
spell that out somewhere.


Do you mean providing a summary of the changes between the existing 
guidelines and these?



## PyPI parity

Every Python package in Fedora **SHOULD** also be available
on [the Python Package Index](https://pypi.org) (PyPI).

The command `pip install PROJECTNAME` **MUST** install the same package
(possibly in a different version),
install nothing,
or fail with a reasonable error message.

If this is not the case, the packager **MUST** contact upstream about this.
The goal is to get the project name registered or blocked on PyPI,
or to otherwise ensure the rule is followed.

To block a project name on PyPI, email
[ad...@pypi.org](mailto:ad...@pypi.org),
giving the project name and explaining the situation
(for example: the package cannot currently be installed via `pip`).
You can ask questions and discuss the process at the [Python
Discourse](https://discuss.python.org/t/block-names/4045).

  > NOTE: Project names that were in Fedora but not on PyPI
  > when these guidelines were proposed
  > are *blocked* from being uploaded to PyPI.
  > This prevents potential trolls from taking them,
  > but it also blocks legitimate owners.
  > If your package is affected, contact the Python SIG
  > or [file a PyPA
issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME)

  > and mention `@encukou`.

This is necessary to protect users,
avoid confusion,
and enable automation as Fedora and upstream ecosystems grow more
integrated.

As always, [specific exceptions can be granted by the Packaging
Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).



@Conan-Kudo:

This is not reasonable to ask of packagers to do. Such a check is difficult to 
do, and there is no particularly compelling reason for making everything 
written in Python using Python build system available in PyPI. Unless you plan 
to provide an automated system to inform PyPI of these things, this is not only 
unreasonable, it is unenforceable.


A lot of stuff in the guidelines is unenforceable, so let's focus on the
"unreasonable" part.

There is no reason to have everything available on PyPI, but I do
believe it's reasonable to *reserve the name* in such cases.

Here's a reason why I want this:

The issue here is that Python tools have access to project names. For
example, I can get the version of Requests using:

  >>> from importlib.metadata import version
  >>> version('requests')
'2.22.0'

Things like this are only useful if we use a common namespace. Upstream,
that namespace *is* PyPI; there's little we can do about that.
If project names mean something else in Fedora than in the wider
ecosystem, we'll get user confusion at best.

(If you use a private package index, like they do at CERN or some
closed-source shops, there can be some collisions -- but in that case
there's a limited number of software authors and users, and a lot more
control over the package set. Conflicts in global repositories of
free/open-source software are much harder to manage.)



Lately, I think about another way to handle this: packages that aren't
on PyPI could not ship the .dist-info at all, and so, they would not
have things like `python3dist(...)` provides. They'd only be usable with
Fedora tooling, not in the wider Python ecosystem.
It's a major case to think out and test, but maybe it would be worth it?



I think omitting the Provides is unfair.


Why?
In my view, `python3dist(...)` is using the

Re: Draft of New Python Packaging Guidelines - 0.2

[Neal Gompa]

On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:
>
> I'll move some discussion here, where it doesn't become part of the
> document:
>
> >
> > On 2020-08-11 14:19, Petr Viktorin wrote:
> >> These Guidelines represent a major rewrite and paradigm shift, and not
> >> all packages are updated to reflect this.
> >> Older guidelines are still being kept up to date, and existing packages
> >> **MAY** use them instead of this document:
> >> * 201x-era [Python packaging
> >> guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
> >> (for packages that use e.g. `%py3_install` or `setup.py install`)
> >> * [Python 2
> >> appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
> >> (for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)
>
>
> @Conan-Kudo:
> > Is there something you've done here to make the new macros unequivocally 
> > better? Do you have automated flavor builds, for example? Right now there 
> > is no effective difference.
>
>
> The new macros allow other build tools than just setuptools.
> They also use upstream metadata for BuildRequires & file lists.
>
> Of course, where possible the changes were backported to the existing
> macros. I don't necessarily see the macros as the main thing that
> changes. But when you look at a specfile, you can usually tell what
> conventions it uses by what macros you see.
>

Those are all nice things, for sure. I think it'd be important to
spell that out somewhere.

> >
> >> ## PyPI parity
> >>
> >> Every Python package in Fedora **SHOULD** also be available
> >> on [the Python Package Index](https://pypi.org) (PyPI).
> >>
> >> The command `pip install PROJECTNAME` **MUST** install the same package
> >> (possibly in a different version),
> >> install nothing,
> >> or fail with a reasonable error message.
> >>
> >> If this is not the case, the packager **MUST** contact upstream about this.
> >> The goal is to get the project name registered or blocked on PyPI,
> >> or to otherwise ensure the rule is followed.
> >>
> >> To block a project name on PyPI, email
> >> [ad...@pypi.org](mailto:ad...@pypi.org),
> >> giving the project name and explaining the situation
> >> (for example: the package cannot currently be installed via `pip`).
> >> You can ask questions and discuss the process at the [Python
> >> Discourse](https://discuss.python.org/t/block-names/4045).
> >>
> >>  > NOTE: Project names that were in Fedora but not on PyPI
> >>  > when these guidelines were proposed
> >>  > are *blocked* from being uploaded to PyPI.
> >>  > This prevents potential trolls from taking them,
> >>  > but it also blocks legitimate owners.
> >>  > If your package is affected, contact the Python SIG
> >>  > or [file a PyPA
> >> issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME)
> >>
> >>  > and mention `@encukou`.
> >>
> >> This is necessary to protect users,
> >> avoid confusion,
> >> and enable automation as Fedora and upstream ecosystems grow more
> >> integrated.
> >>
> >> As always, [specific exceptions can be granted by the Packaging
> >> Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).
>
>
> @Conan-Kudo:
> > This is not reasonable to ask of packagers to do. Such a check is difficult 
> > to do, and there is no particularly compelling reason for making everything 
> > written in Python using Python build system available in PyPI. Unless you 
> > plan to provide an automated system to inform PyPI of these things, this is 
> > not only unreasonable, it is unenforceable.
>
> A lot of stuff in the guidelines is unenforceable, so let's focus on the
> "unreasonable" part.
>
> There is no reason to have everything available on PyPI, but I do
> believe it's reasonable to *reserve the name* in such cases.
>
> Here's a reason why I want this:
>
> The issue here is that Python tools have access to project names. For
> example, I can get the version of Requests using:
>
>  >>> from importlib.metadata import version
>  >>> version('requests')
> '2.22.0'
>
> Things like this are only useful if we use a common namespace. Upstream,
> that namespace *is* PyPI; there's little we can do about that.
> If project names mean something else in Fedora than in the wider
> ecosystem, we'll get user confusion at best.
>
> (If you use a private package index, like they do at CERN or some
> closed-source shops, there can be some collisions -- but in that case
> there's a limited number of software authors and users, and a lot more
> control over the package set. Conflicts in global repositories of
> free/open-source software are much harder to manage.)
>
>
>
> Lately, I think about another way to handle this: packages that aren't
> on PyPI could not ship the .dist-info at all, and so, they would not
> have things like `python3dist(...)` provides. They'd only be usable with
> Fedora 

[RELEASE] Python 3.9.0rc1 is now available

[Miro Hrončok]

This has been updated in Fedora rawhide.

The Fedora 33 update waits for the successful compose:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3d34a62850

The updates appear to be ABI compatible, so there is no need for a targeted 
rebuild.

Fedora 32 and 31 updates are pending:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ce74609c79
https://bodhi.fedoraproject.org/updates/FEDORA-2020-85cca90ce8


 Forwarded Message 
Subject:[Python-Dev] [RELEASE] Python 3.9.0rc1 is now available
Date:   Tue, 11 Aug 2020 23:48:59 +0200
From:   Łukasz Langa 
To: 	python-committ...@python.org, python-...@python.org, 
python-l...@python.org, python-annou...@python.org




Python 3.9.0 is*almost*ready. This release,*3.9.0rc1*, is the penultimate 
release preview. You can get it here:


https://www.python.org/downloads/release/python-390rc1/

Entering the release candidate phase, only reviewed code changes which are clear 
bug fixes are allowed between this release candidate and the final release. The 
second candidate and the last planned release preview is currently planned for 
2020-09-14.


Please keep in mind that this is a preview release and its use 
is*not*recommended for production environments.



Calls to action


Core developers: all eyes on the docs now

  * Are all*your*changes properly documented?
  * Did you notice*other*changes you know of to have insufficient documentation?


Community members

We*strongly encourage*maintainers of third-party Python projects to prepare 
their projects for 3.9 compatibility during this phase. As always, report any 
issues tothe Python bug tracker .



Installer news

This is the first version of Python to default to the 64-bit installer on 
Windows. The installer now also actively disallows installation on Windows 7. 
Python 3.9 is incompatible with this unsupported version of Windows.



Major new features of the 3.9 series, compared to 3.8

Some of the new major new features and changes in Python 3.9 are:

  * PEP 584 , Union Operators 
in|dict|
  * PEP 585 , Type Hinting Generics
In Standard Collections
  * PEP 593 , Flexible function and
variable annotations
  * PEP 602 , Python adopts a stable
annual release cadence
  * PEP 615 , Support for the IANA
Time Zone Database in the Standard Library
  * PEP 616 , String methods to
remove prefixes and suffixes
  * PEP 617 , New PEG parser for 
CPython
  * BPO 38379 , garbage collection does not
block on resurrected objects;
  * BPO 38692 , os.pidfd_open added that
allows process management without races and signals;
  * BPO 39926 , Unicode support updated to
version 13.0.0;
  * BPO 1635741 , when Python is
initialized multiple times in the same process, it does not leak memory 
anymore;

  * A number of Python builtins (range, tuple, set, frozenset, list, dict) are
now sped up usingPEP 590 
vectorcall;
  * A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars,
_crypt, _functools, _json, _locale, operator, resource, time, _weakref) now
use multiphase initialization as defined byPEP 489
;
  * A number of standard library modules (audioop, ast, grp, _hashlib, pwd,
_posixsubprocess, random, select, struct, termios, zlib) are now using the
stable ABI defined byPEP 384 .


___
Python-Dev mailing list -- python-...@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-...@python.org/message/FFVG5DAE7RHE5ZYUVVJW5TPAZ2ALRFHB/
Code of Conduct: http://python.org/psf/codeofconduct/

___
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 - 0.2

[Petr Viktorin]

I'll move some discussion here, where it doesn't become part of the 
document:




On 2020-08-11 14:19, Petr Viktorin wrote:
These Guidelines represent a major rewrite and paradigm shift, and not 
all packages are updated to reflect this.
Older guidelines are still being kept up to date, and existing packages 
**MAY** use them instead of this document:
* 201x-era [Python packaging 
guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/) 
(for packages that use e.g. `%py3_install` or `setup.py install`)
* [Python 2 
appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages) 
(for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)



@Conan-Kudo:

Is there something you've done here to make the new macros unequivocally 
better? Do you have automated flavor builds, for example? Right now there is no 
effective difference.



The new macros allow other build tools than just setuptools.
They also use upstream metadata for BuildRequires & file lists.

Of course, where possible the changes were backported to the existing 
macros. I don't necessarily see the macros as the main thing that 
changes. But when you look at a specfile, you can usually tell what 
conventions it uses by what macros you see.





## PyPI parity

Every Python package in Fedora **SHOULD** also be available
on [the Python Package Index](https://pypi.org) (PyPI).

The command `pip install PROJECTNAME` **MUST** install the same package
(possibly in a different version),
install nothing,
or fail with a reasonable error message.

If this is not the case, the packager **MUST** contact upstream about this.
The goal is to get the project name registered or blocked on PyPI,
or to otherwise ensure the rule is followed.

To block a project name on PyPI, email 
[ad...@pypi.org](mailto:ad...@pypi.org),

giving the project name and explaining the situation
(for example: the package cannot currently be installed via `pip`).
You can ask questions and discuss the process at the [Python 
Discourse](https://discuss.python.org/t/block-names/4045).


 > NOTE: Project names that were in Fedora but not on PyPI
 > when these guidelines were proposed
 > are *blocked* from being uploaded to PyPI.
 > This prevents potential trolls from taking them,
 > but it also blocks legitimate owners.
 > If your package is affected, contact the Python SIG
 > or [file a PyPA 
issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME) 


 > and mention `@encukou`.

This is necessary to protect users,
avoid confusion,
and enable automation as Fedora and upstream ecosystems grow more 
integrated.


As always, [specific exceptions can be granted by the Packaging 
Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy). 



@Conan-Kudo:

This is not reasonable to ask of packagers to do. Such a check is difficult to 
do, and there is no particularly compelling reason for making everything 
written in Python using Python build system available in PyPI. Unless you plan 
to provide an automated system to inform PyPI of these things, this is not only 
unreasonable, it is unenforceable.


A lot of stuff in the guidelines is unenforceable, so let's focus on the 
"unreasonable" part.


There is no reason to have everything available on PyPI, but I do 
believe it's reasonable to *reserve the name* in such cases.


Here's a reason why I want this:

The issue here is that Python tools have access to project names. For 
example, I can get the version of Requests using:


>>> from importlib.metadata import version
>>> version('requests')
'2.22.0'

Things like this are only useful if we use a common namespace. Upstream, 
that namespace *is* PyPI; there's little we can do about that.
If project names mean something else in Fedora than in the wider 
ecosystem, we'll get user confusion at best.


(If you use a private package index, like they do at CERN or some 
closed-source shops, there can be some collisions -- but in that case 
there's a limited number of software authors and users, and a lot more 
control over the package set. Conflicts in global repositories of 
free/open-source software are much harder to manage.)




Lately, I think about another way to handle this: packages that aren't 
on PyPI could not ship the .dist-info at all, and so, they would not 
have things like `python3dist(...)` provides. They'd only be usable with 
Fedora tooling, not in the wider Python ecosystem.

It's a major case to think out and test, but maybe it would be worth it?
___
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
Li