You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tooling.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2026/06/30 12:29:53 UTC
Implicit namespaces for package repositories (PyPI) accepted
Hello Dear infrastructure team and tooling,
I would like to let you know that yesterday, finally, after about 2 years
of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
the new council finally accepted "PEP-752 Implicit namespaces for package
repositories," which I co-authored.
https://github.com/python/peps/pull/5009
*What does this mean for the ASF and PMCs ?*
There is a reference implementation of it for PyPI, so it is likely now,
after the PEP is accepted, it will be implemented in months rather than
years. And once implemented, the ASF will be able to claim the "apache-"
ownership for PyPI packages.
This means that the ASF's expectation that Python Packages are named with
"apache-" prefix will be not only practical, but also enforceable (nobody
else will be able to publish packages with "apache-" prefix. It will make
our lives easier to remove anyone who has already done this. We will only
have to prove **ONCE** that our organisation - managed by Infra - has the
right to use the "apache-" prefix. Then, all cases where someone already
uses an "apache-" package will be much faster - almost automatic—to process
following PEP-541 (https://peps.python.org/pep-0541/).
Currently, it currently takes months to remove someone who is using a name
we would like to use. Recent example
https://github.com/pypi/support/issues/10716
*What does it mean for Infra and Tooling?*
For now - just awareness.
If Infra prioritizes it, action will likely be needed in a few months, once
the implementation is completed and released in PyPI. We should start the
process of;
a) Requesting the Infra-managed organization to get "apache-" prefix
exclusivity
b) Moving all ASF projects that use PyPI to the new organisation
c) Starting a process to "boot" all non-apache projects using the "apache-"
prefix, requiring them to use other names and allowing us to take over
management of the existing projects (basically disabling them)
d) That will also allow connecting Apache Trusted Releases with Trusted
Publishing for the organization and enable all our Python projects to use
trusted publishing.
For incubator - it means that the "apache-" rule will finally be
enforceable and we will always be able to choose the right package name and
make sure it will not be taken by others - either maliciously or
accidentally - for any new projects we incubate.
I am happy to help in my volunteer capacity with all of these efforts,
including leading the move of moving all 200+ Airflow projects to the new
organization.
This all depends on Infra and Tooling priorities, so I am letting you know
early so you can decide on priorities and plan accordingly.
Happy to answer any questions there.
J.
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by tison <wa...@gmail.com>.
This is very clear. Thank you!
Best,
tison.
Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 23:22写道：
> > By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] be forced to rename to apache-opendal?
>
> I think it will really depend on the ASF's policies (if someone wants
> to make it a mandatory policy). I personally consider it something
> that will allow the ASF to prevent "apache-*" from being "hijacked" by
> others, not the other way round.
> The "Implicit namespace" concept refers more to the fact that in
> "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> implicit namespace as "apache" and manage it under the organisation
> that "owns" it.
>
> But in general—no. In this case "opendal" is both the name in PyPI
> **and** name in `pyproject.toml`.toml - they are the same. But if the
> Opendal PMC wants to do this—even voluntarily, and even today —it's
> entirely possible to make a fairly transparent redirection if desired.
> We've done this several times in the past. It's generally enough to
> publish a new version of the "empty" opendal package that has
> "apache-opendal" as a dependency—this can provide backward
> compatibility. So you would have to have the pipeline where you build
> the "empty" package and publish it alongside the "apache-opendal" one.
>
> J.
>
> On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
> >
> > Hi Jarek,
> >
> > Thanks for your effort in moving this forward!
> >
> > I have one question:
> >
> > By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] forcely renamed to apache-opendal?
> >
> > [1] https://pypi.org/project/opendal/
> >
> > That is, the name "implicit namespaces" seems to imply that the
> exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
> logic.
> >
> > If that is the case, users may still use "opendal = ..." in
> pyproject.toml and lock the dependency to apache-opendal correctly. Or I
> understand it wrong?
> >
> > BTW, the recipients have both public and private mailing lists; I think
> it would be better to stay in public and only keep the private ones in bcc.
> >
> > Best,
> > tison.
> >
> >
> > Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> >>
> >> Hello Dear infrastructure team and tooling,
> >>
> >> I would like to let you know that yesterday, finally, after about 2
> years
> >> of back-and-forth and PEP-772 changing how the Packaging Team accepts
> PEPs,
> >> the new council finally accepted "PEP-752 Implicit namespaces for
> package
> >> repositories," which I co-authored.
> >>
> >> https://github.com/python/peps/pull/5009
> >>
> >> *What does this mean for the ASF and PMCs ?*
> >>
> >> There is a reference implementation of it for PyPI, so it is likely now,
> >> after the PEP is accepted, it will be implemented in months rather than
> >> years. And once implemented, the ASF will be able to claim the "apache-"
> >> ownership for PyPI packages.
> >>
> >> This means that the ASF's expectation that Python Packages are named
> with
> >> "apache-" prefix will be not only practical, but also enforceable
> (nobody
> >> else will be able to publish packages with "apache-" prefix. It will
> make
> >> our lives easier to remove anyone who has already done this. We will
> only
> >> have to prove **ONCE** that our organisation - managed by Infra - has
> the
> >> right to use the "apache-" prefix. Then, all cases where someone already
> >> uses an "apache-" package will be much faster - almost automatic—to
> process
> >> following PEP-541 (https://peps.python.org/pep-0541/).
> >>
> >> Currently, it currently takes months to remove someone who is using a
> name
> >> we would like to use. Recent example
> >> https://github.com/pypi/support/issues/10716
> >>
> >> *What does it mean for Infra and Tooling?*
> >>
> >> For now - just awareness.
> >>
> >> If Infra prioritizes it, action will likely be needed in a few months,
> once
> >> the implementation is completed and released in PyPI. We should start
> the
> >> process of;
> >>
> >> a) Requesting the Infra-managed organization to get "apache-" prefix
> >> exclusivity
> >> b) Moving all ASF projects that use PyPI to the new organisation
> >> c) Starting a process to "boot" all non-apache projects using the
> "apache-"
> >> prefix, requiring them to use other names and allowing us to take over
> >> management of the existing projects (basically disabling them)
> >> d) That will also allow connecting Apache Trusted Releases with Trusted
> >> Publishing for the organization and enable all our Python projects to
> use
> >> trusted publishing.
> >>
> >> For incubator - it means that the "apache-" rule will finally be
> >> enforceable and we will always be able to choose the right package name
> and
> >> make sure it will not be taken by others - either maliciously or
> >> accidentally - for any new projects we incubate.
> >>
> >> I am happy to help in my volunteer capacity with all of these efforts,
> >> including leading the move of moving all 200+ Airflow projects to the
> new
> >> organization.
> >>
> >> This all depends on Infra and Tooling priorities, so I am letting you
> know
> >> early so you can decide on priorities and plan accordingly.
> >>
> >> Happy to answer any questions there.
> >>
> >> J.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Kaxil Naik <ka...@gmail.com>.
Finally! Good work pushing this through Jarek
On Tue, 30 Jun 2026 at 21:01, Dave Fisher <wa...@apache.org> wrote:
> Jarek - I will echo Tison’s thanks!
>
> Non-Apache Distributions like PyPi are on the ATR development list once we
> have the Beta fully functional.
>
> Current policy for these convenience binary packages is centered around
> proper marking of packages. There is a diversity of approaches across
> ecosystems in how packages are released. The tooling team is surveying the
> situation focusing first on GitHub Actions and Workflows used on Apache
> repositories. Our current goals are:
>
> 1. Recommend best practices for releasing distributions.
> 2. Surveying channels for ASF distributions.
> 3. Identifying distributions made without expected project governance.
> 4. Cataloging distributions in ATR’s new release catalog.
>
> We are in discovery phase, but could be working on ATR code as early as
> August.
>
> A discussion will be needed with Infrastructure about whether ASF accounts
> are optional or required, and answers may differ depending on which
> ecosystem.
>
> Best,
> Dave
>
>
> > On Jun 30, 2026, at 8:22 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> >> By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] be forced to rename to apache-opendal?
> >
> > I think it will really depend on the ASF's policies (if someone wants
> > to make it a mandatory policy). I personally consider it something
> > that will allow the ASF to prevent "apache-*" from being "hijacked" by
> > others, not the other way round.
> > The "Implicit namespace" concept refers more to the fact that in
> > "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> > implicit namespace as "apache" and manage it under the organisation
> > that "owns" it.
> >
> > But in general—no. In this case "opendal" is both the name in PyPI
> > **and** name in `pyproject.toml`.toml - they are the same. But if the
> > Opendal PMC wants to do this—even voluntarily, and even today —it's
> > entirely possible to make a fairly transparent redirection if desired.
> > We've done this several times in the past. It's generally enough to
> > publish a new version of the "empty" opendal package that has
> > "apache-opendal" as a dependency—this can provide backward
> > compatibility. So you would have to have the pipeline where you build
> > the "empty" package and publish it alongside the "apache-opendal" one.
> >
> > J.
> >
> > On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
> >>
> >> Hi Jarek,
> >>
> >> Thanks for your effort in moving this forward!
> >>
> >> I have one question:
> >>
> >> By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] forcely renamed to apache-opendal?
> >>
> >> [1] https://pypi.org/project/opendal/
> >>
> >> That is, the name "implicit namespaces" seems to imply that the
> exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
> logic.
> >>
> >> If that is the case, users may still use "opendal = ..." in
> pyproject.toml and lock the dependency to apache-opendal correctly. Or I
> understand it wrong?
> >>
> >> BTW, the recipients have both public and private mailing lists; I think
> it would be better to stay in public and only keep the private ones in bcc.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> >>>
> >>> Hello Dear infrastructure team and tooling,
> >>>
> >>> I would like to let you know that yesterday, finally, after about 2
> years
> >>> of back-and-forth and PEP-772 changing how the Packaging Team accepts
> PEPs,
> >>> the new council finally accepted "PEP-752 Implicit namespaces for
> package
> >>> repositories," which I co-authored.
> >>>
> >>> https://github.com/python/peps/pull/5009
> >>>
> >>> *What does this mean for the ASF and PMCs ?*
> >>>
> >>> There is a reference implementation of it for PyPI, so it is likely
> now,
> >>> after the PEP is accepted, it will be implemented in months rather than
> >>> years. And once implemented, the ASF will be able to claim the
> "apache-"
> >>> ownership for PyPI packages.
> >>>
> >>> This means that the ASF's expectation that Python Packages are named
> with
> >>> "apache-" prefix will be not only practical, but also enforceable
> (nobody
> >>> else will be able to publish packages with "apache-" prefix. It will
> make
> >>> our lives easier to remove anyone who has already done this. We will
> only
> >>> have to prove **ONCE** that our organisation - managed by Infra - has
> the
> >>> right to use the "apache-" prefix. Then, all cases where someone
> already
> >>> uses an "apache-" package will be much faster - almost automatic—to
> process
> >>> following PEP-541 (https://peps.python.org/pep-0541/).
> >>>
> >>> Currently, it currently takes months to remove someone who is using a
> name
> >>> we would like to use. Recent example
> >>> https://github.com/pypi/support/issues/10716
> >>>
> >>> *What does it mean for Infra and Tooling?*
> >>>
> >>> For now - just awareness.
> >>>
> >>> If Infra prioritizes it, action will likely be needed in a few months,
> once
> >>> the implementation is completed and released in PyPI. We should start
> the
> >>> process of;
> >>>
> >>> a) Requesting the Infra-managed organization to get "apache-" prefix
> >>> exclusivity
> >>> b) Moving all ASF projects that use PyPI to the new organisation
> >>> c) Starting a process to "boot" all non-apache projects using the
> "apache-"
> >>> prefix, requiring them to use other names and allowing us to take over
> >>> management of the existing projects (basically disabling them)
> >>> d) That will also allow connecting Apache Trusted Releases with Trusted
> >>> Publishing for the organization and enable all our Python projects to
> use
> >>> trusted publishing.
> >>>
> >>> For incubator - it means that the "apache-" rule will finally be
> >>> enforceable and we will always be able to choose the right package
> name and
> >>> make sure it will not be taken by others - either maliciously or
> >>> accidentally - for any new projects we incubate.
> >>>
> >>> I am happy to help in my volunteer capacity with all of these efforts,
> >>> including leading the move of moving all 200+ Airflow projects to the
> new
> >>> organization.
> >>>
> >>> This all depends on Infra and Tooling priorities, so I am letting you
> know
> >>> early so you can decide on priorities and plan accordingly.
> >>>
> >>> Happy to answer any questions there.
> >>>
> >>> J.
>
>
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Kaxil Naik <ka...@gmail.com>.
Finally! Good work pushing this through Jarek
On Tue, 30 Jun 2026 at 21:01, Dave Fisher <wa...@apache.org> wrote:
> Jarek - I will echo Tison’s thanks!
>
> Non-Apache Distributions like PyPi are on the ATR development list once we
> have the Beta fully functional.
>
> Current policy for these convenience binary packages is centered around
> proper marking of packages. There is a diversity of approaches across
> ecosystems in how packages are released. The tooling team is surveying the
> situation focusing first on GitHub Actions and Workflows used on Apache
> repositories. Our current goals are:
>
> 1. Recommend best practices for releasing distributions.
> 2. Surveying channels for ASF distributions.
> 3. Identifying distributions made without expected project governance.
> 4. Cataloging distributions in ATR’s new release catalog.
>
> We are in discovery phase, but could be working on ATR code as early as
> August.
>
> A discussion will be needed with Infrastructure about whether ASF accounts
> are optional or required, and answers may differ depending on which
> ecosystem.
>
> Best,
> Dave
>
>
> > On Jun 30, 2026, at 8:22 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> >> By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] be forced to rename to apache-opendal?
> >
> > I think it will really depend on the ASF's policies (if someone wants
> > to make it a mandatory policy). I personally consider it something
> > that will allow the ASF to prevent "apache-*" from being "hijacked" by
> > others, not the other way round.
> > The "Implicit namespace" concept refers more to the fact that in
> > "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> > implicit namespace as "apache" and manage it under the organisation
> > that "owns" it.
> >
> > But in general—no. In this case "opendal" is both the name in PyPI
> > **and** name in `pyproject.toml`.toml - they are the same. But if the
> > Opendal PMC wants to do this—even voluntarily, and even today —it's
> > entirely possible to make a fairly transparent redirection if desired.
> > We've done this several times in the past. It's generally enough to
> > publish a new version of the "empty" opendal package that has
> > "apache-opendal" as a dependency—this can provide backward
> > compatibility. So you would have to have the pipeline where you build
> > the "empty" package and publish it alongside the "apache-opendal" one.
> >
> > J.
> >
> > On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
> >>
> >> Hi Jarek,
> >>
> >> Thanks for your effort in moving this forward!
> >>
> >> I have one question:
> >>
> >> By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] forcely renamed to apache-opendal?
> >>
> >> [1] https://pypi.org/project/opendal/
> >>
> >> That is, the name "implicit namespaces" seems to imply that the
> exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
> logic.
> >>
> >> If that is the case, users may still use "opendal = ..." in
> pyproject.toml and lock the dependency to apache-opendal correctly. Or I
> understand it wrong?
> >>
> >> BTW, the recipients have both public and private mailing lists; I think
> it would be better to stay in public and only keep the private ones in bcc.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> >>>
> >>> Hello Dear infrastructure team and tooling,
> >>>
> >>> I would like to let you know that yesterday, finally, after about 2
> years
> >>> of back-and-forth and PEP-772 changing how the Packaging Team accepts
> PEPs,
> >>> the new council finally accepted "PEP-752 Implicit namespaces for
> package
> >>> repositories," which I co-authored.
> >>>
> >>> https://github.com/python/peps/pull/5009
> >>>
> >>> *What does this mean for the ASF and PMCs ?*
> >>>
> >>> There is a reference implementation of it for PyPI, so it is likely
> now,
> >>> after the PEP is accepted, it will be implemented in months rather than
> >>> years. And once implemented, the ASF will be able to claim the
> "apache-"
> >>> ownership for PyPI packages.
> >>>
> >>> This means that the ASF's expectation that Python Packages are named
> with
> >>> "apache-" prefix will be not only practical, but also enforceable
> (nobody
> >>> else will be able to publish packages with "apache-" prefix. It will
> make
> >>> our lives easier to remove anyone who has already done this. We will
> only
> >>> have to prove **ONCE** that our organisation - managed by Infra - has
> the
> >>> right to use the "apache-" prefix. Then, all cases where someone
> already
> >>> uses an "apache-" package will be much faster - almost automatic—to
> process
> >>> following PEP-541 (https://peps.python.org/pep-0541/).
> >>>
> >>> Currently, it currently takes months to remove someone who is using a
> name
> >>> we would like to use. Recent example
> >>> https://github.com/pypi/support/issues/10716
> >>>
> >>> *What does it mean for Infra and Tooling?*
> >>>
> >>> For now - just awareness.
> >>>
> >>> If Infra prioritizes it, action will likely be needed in a few months,
> once
> >>> the implementation is completed and released in PyPI. We should start
> the
> >>> process of;
> >>>
> >>> a) Requesting the Infra-managed organization to get "apache-" prefix
> >>> exclusivity
> >>> b) Moving all ASF projects that use PyPI to the new organisation
> >>> c) Starting a process to "boot" all non-apache projects using the
> "apache-"
> >>> prefix, requiring them to use other names and allowing us to take over
> >>> management of the existing projects (basically disabling them)
> >>> d) That will also allow connecting Apache Trusted Releases with Trusted
> >>> Publishing for the organization and enable all our Python projects to
> use
> >>> trusted publishing.
> >>>
> >>> For incubator - it means that the "apache-" rule will finally be
> >>> enforceable and we will always be able to choose the right package
> name and
> >>> make sure it will not be taken by others - either maliciously or
> >>> accidentally - for any new projects we incubate.
> >>>
> >>> I am happy to help in my volunteer capacity with all of these efforts,
> >>> including leading the move of moving all 200+ Airflow projects to the
> new
> >>> organization.
> >>>
> >>> This all depends on Infra and Tooling priorities, so I am letting you
> know
> >>> early so you can decide on priorities and plan accordingly.
> >>>
> >>> Happy to answer any questions there.
> >>>
> >>> J.
>
>
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Dave Fisher <wa...@apache.org>.
Jarek - I will echo Tison’s thanks!
Non-Apache Distributions like PyPi are on the ATR development list once we have the Beta fully functional.
Current policy for these convenience binary packages is centered around proper marking of packages. There is a diversity of approaches across ecosystems in how packages are released. The tooling team is surveying the situation focusing first on GitHub Actions and Workflows used on Apache repositories. Our current goals are:
1. Recommend best practices for releasing distributions.
2. Surveying channels for ASF distributions.
3. Identifying distributions made without expected project governance.
4. Cataloging distributions in ATR’s new release catalog.
We are in discovery phase, but could be working on ATR code as early as August.
A discussion will be needed with Infrastructure about whether ASF accounts are optional or required, and answers may differ depending on which ecosystem.
Best,
Dave
> On Jun 30, 2026, at 8:22 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] be forced to rename to apache-opendal?
>
> I think it will really depend on the ASF's policies (if someone wants
> to make it a mandatory policy). I personally consider it something
> that will allow the ASF to prevent "apache-*" from being "hijacked" by
> others, not the other way round.
> The "Implicit namespace" concept refers more to the fact that in
> "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> implicit namespace as "apache" and manage it under the organisation
> that "owns" it.
>
> But in general—no. In this case "opendal" is both the name in PyPI
> **and** name in `pyproject.toml`.toml - they are the same. But if the
> Opendal PMC wants to do this—even voluntarily, and even today —it's
> entirely possible to make a fairly transparent redirection if desired.
> We've done this several times in the past. It's generally enough to
> publish a new version of the "empty" opendal package that has
> "apache-opendal" as a dependency—this can provide backward
> compatibility. So you would have to have the pipeline where you build
> the "empty" package and publish it alongside the "apache-opendal" one.
>
> J.
>
> On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
>>
>> Hi Jarek,
>>
>> Thanks for your effort in moving this forward!
>>
>> I have one question:
>>
>> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] forcely renamed to apache-opendal?
>>
>> [1] https://pypi.org/project/opendal/
>>
>> That is, the name "implicit namespaces" seems to imply that the exclusive "apache-" prefix is optional, i.e, there is some auto-prefix logic.
>>
>> If that is the case, users may still use "opendal = ..." in pyproject.toml and lock the dependency to apache-opendal correctly. Or I understand it wrong?
>>
>> BTW, the recipients have both public and private mailing lists; I think it would be better to stay in public and only keep the private ones in bcc.
>>
>> Best,
>> tison.
>>
>>
>> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
>>>
>>> Hello Dear infrastructure team and tooling,
>>>
>>> I would like to let you know that yesterday, finally, after about 2 years
>>> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
>>> the new council finally accepted "PEP-752 Implicit namespaces for package
>>> repositories," which I co-authored.
>>>
>>> https://github.com/python/peps/pull/5009
>>>
>>> *What does this mean for the ASF and PMCs ?*
>>>
>>> There is a reference implementation of it for PyPI, so it is likely now,
>>> after the PEP is accepted, it will be implemented in months rather than
>>> years. And once implemented, the ASF will be able to claim the "apache-"
>>> ownership for PyPI packages.
>>>
>>> This means that the ASF's expectation that Python Packages are named with
>>> "apache-" prefix will be not only practical, but also enforceable (nobody
>>> else will be able to publish packages with "apache-" prefix. It will make
>>> our lives easier to remove anyone who has already done this. We will only
>>> have to prove **ONCE** that our organisation - managed by Infra - has the
>>> right to use the "apache-" prefix. Then, all cases where someone already
>>> uses an "apache-" package will be much faster - almost automatic—to process
>>> following PEP-541 (https://peps.python.org/pep-0541/).
>>>
>>> Currently, it currently takes months to remove someone who is using a name
>>> we would like to use. Recent example
>>> https://github.com/pypi/support/issues/10716
>>>
>>> *What does it mean for Infra and Tooling?*
>>>
>>> For now - just awareness.
>>>
>>> If Infra prioritizes it, action will likely be needed in a few months, once
>>> the implementation is completed and released in PyPI. We should start the
>>> process of;
>>>
>>> a) Requesting the Infra-managed organization to get "apache-" prefix
>>> exclusivity
>>> b) Moving all ASF projects that use PyPI to the new organisation
>>> c) Starting a process to "boot" all non-apache projects using the "apache-"
>>> prefix, requiring them to use other names and allowing us to take over
>>> management of the existing projects (basically disabling them)
>>> d) That will also allow connecting Apache Trusted Releases with Trusted
>>> Publishing for the organization and enable all our Python projects to use
>>> trusted publishing.
>>>
>>> For incubator - it means that the "apache-" rule will finally be
>>> enforceable and we will always be able to choose the right package name and
>>> make sure it will not be taken by others - either maliciously or
>>> accidentally - for any new projects we incubate.
>>>
>>> I am happy to help in my volunteer capacity with all of these efforts,
>>> including leading the move of moving all 200+ Airflow projects to the new
>>> organization.
>>>
>>> This all depends on Infra and Tooling priorities, so I am letting you know
>>> early so you can decide on priorities and plan accordingly.
>>>
>>> Happy to answer any questions there.
>>>
>>> J.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Dave Fisher <wa...@apache.org>.
Jarek - I will echo Tison’s thanks!
Non-Apache Distributions like PyPi are on the ATR development list once we have the Beta fully functional.
Current policy for these convenience binary packages is centered around proper marking of packages. There is a diversity of approaches across ecosystems in how packages are released. The tooling team is surveying the situation focusing first on GitHub Actions and Workflows used on Apache repositories. Our current goals are:
1. Recommend best practices for releasing distributions.
2. Surveying channels for ASF distributions.
3. Identifying distributions made without expected project governance.
4. Cataloging distributions in ATR’s new release catalog.
We are in discovery phase, but could be working on ATR code as early as August.
A discussion will be needed with Infrastructure about whether ASF accounts are optional or required, and answers may differ depending on which ecosystem.
Best,
Dave
> On Jun 30, 2026, at 8:22 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] be forced to rename to apache-opendal?
>
> I think it will really depend on the ASF's policies (if someone wants
> to make it a mandatory policy). I personally consider it something
> that will allow the ASF to prevent "apache-*" from being "hijacked" by
> others, not the other way round.
> The "Implicit namespace" concept refers more to the fact that in
> "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> implicit namespace as "apache" and manage it under the organisation
> that "owns" it.
>
> But in general—no. In this case "opendal" is both the name in PyPI
> **and** name in `pyproject.toml`.toml - they are the same. But if the
> Opendal PMC wants to do this—even voluntarily, and even today —it's
> entirely possible to make a fairly transparent redirection if desired.
> We've done this several times in the past. It's generally enough to
> publish a new version of the "empty" opendal package that has
> "apache-opendal" as a dependency—this can provide backward
> compatibility. So you would have to have the pipeline where you build
> the "empty" package and publish it alongside the "apache-opendal" one.
>
> J.
>
> On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
>>
>> Hi Jarek,
>>
>> Thanks for your effort in moving this forward!
>>
>> I have one question:
>>
>> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] forcely renamed to apache-opendal?
>>
>> [1] https://pypi.org/project/opendal/
>>
>> That is, the name "implicit namespaces" seems to imply that the exclusive "apache-" prefix is optional, i.e, there is some auto-prefix logic.
>>
>> If that is the case, users may still use "opendal = ..." in pyproject.toml and lock the dependency to apache-opendal correctly. Or I understand it wrong?
>>
>> BTW, the recipients have both public and private mailing lists; I think it would be better to stay in public and only keep the private ones in bcc.
>>
>> Best,
>> tison.
>>
>>
>> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
>>>
>>> Hello Dear infrastructure team and tooling,
>>>
>>> I would like to let you know that yesterday, finally, after about 2 years
>>> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
>>> the new council finally accepted "PEP-752 Implicit namespaces for package
>>> repositories," which I co-authored.
>>>
>>> https://github.com/python/peps/pull/5009
>>>
>>> *What does this mean for the ASF and PMCs ?*
>>>
>>> There is a reference implementation of it for PyPI, so it is likely now,
>>> after the PEP is accepted, it will be implemented in months rather than
>>> years. And once implemented, the ASF will be able to claim the "apache-"
>>> ownership for PyPI packages.
>>>
>>> This means that the ASF's expectation that Python Packages are named with
>>> "apache-" prefix will be not only practical, but also enforceable (nobody
>>> else will be able to publish packages with "apache-" prefix. It will make
>>> our lives easier to remove anyone who has already done this. We will only
>>> have to prove **ONCE** that our organisation - managed by Infra - has the
>>> right to use the "apache-" prefix. Then, all cases where someone already
>>> uses an "apache-" package will be much faster - almost automatic—to process
>>> following PEP-541 (https://peps.python.org/pep-0541/).
>>>
>>> Currently, it currently takes months to remove someone who is using a name
>>> we would like to use. Recent example
>>> https://github.com/pypi/support/issues/10716
>>>
>>> *What does it mean for Infra and Tooling?*
>>>
>>> For now - just awareness.
>>>
>>> If Infra prioritizes it, action will likely be needed in a few months, once
>>> the implementation is completed and released in PyPI. We should start the
>>> process of;
>>>
>>> a) Requesting the Infra-managed organization to get "apache-" prefix
>>> exclusivity
>>> b) Moving all ASF projects that use PyPI to the new organisation
>>> c) Starting a process to "boot" all non-apache projects using the "apache-"
>>> prefix, requiring them to use other names and allowing us to take over
>>> management of the existing projects (basically disabling them)
>>> d) That will also allow connecting Apache Trusted Releases with Trusted
>>> Publishing for the organization and enable all our Python projects to use
>>> trusted publishing.
>>>
>>> For incubator - it means that the "apache-" rule will finally be
>>> enforceable and we will always be able to choose the right package name and
>>> make sure it will not be taken by others - either maliciously or
>>> accidentally - for any new projects we incubate.
>>>
>>> I am happy to help in my volunteer capacity with all of these efforts,
>>> including leading the move of moving all 200+ Airflow projects to the new
>>> organization.
>>>
>>> This all depends on Infra and Tooling priorities, so I am letting you know
>>> early so you can decide on priorities and plan accordingly.
>>>
>>> Happy to answer any questions there.
>>>
>>> J.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by tison <wa...@gmail.com>.
This is very clear. Thank you!
Best,
tison.
Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 23:22写道：
> > By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] be forced to rename to apache-opendal?
>
> I think it will really depend on the ASF's policies (if someone wants
> to make it a mandatory policy). I personally consider it something
> that will allow the ASF to prevent "apache-*" from being "hijacked" by
> others, not the other way round.
> The "Implicit namespace" concept refers more to the fact that in
> "apache-NNNN" (or any other prefix), PyPI will be able to derive the
> implicit namespace as "apache" and manage it under the organisation
> that "owns" it.
>
> But in general—no. In this case "opendal" is both the name in PyPI
> **and** name in `pyproject.toml`.toml - they are the same. But if the
> Opendal PMC wants to do this—even voluntarily, and even today —it's
> entirely possible to make a fairly transparent redirection if desired.
> We've done this several times in the past. It's generally enough to
> publish a new version of the "empty" opendal package that has
> "apache-opendal" as a dependency—this can provide backward
> compatibility. So you would have to have the pipeline where you build
> the "empty" package and publish it alongside the "apache-opendal" one.
>
> J.
>
> On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
> >
> > Hi Jarek,
> >
> > Thanks for your effort in moving this forward!
> >
> > I have one question:
> >
> > By owning the "apache-" prefix exclusivity, will existing ASF projects
> like opendal [1] forcely renamed to apache-opendal?
> >
> > [1] https://pypi.org/project/opendal/
> >
> > That is, the name "implicit namespaces" seems to imply that the
> exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
> logic.
> >
> > If that is the case, users may still use "opendal = ..." in
> pyproject.toml and lock the dependency to apache-opendal correctly. Or I
> understand it wrong?
> >
> > BTW, the recipients have both public and private mailing lists; I think
> it would be better to stay in public and only keep the private ones in bcc.
> >
> > Best,
> > tison.
> >
> >
> > Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> >>
> >> Hello Dear infrastructure team and tooling,
> >>
> >> I would like to let you know that yesterday, finally, after about 2
> years
> >> of back-and-forth and PEP-772 changing how the Packaging Team accepts
> PEPs,
> >> the new council finally accepted "PEP-752 Implicit namespaces for
> package
> >> repositories," which I co-authored.
> >>
> >> https://github.com/python/peps/pull/5009
> >>
> >> *What does this mean for the ASF and PMCs ?*
> >>
> >> There is a reference implementation of it for PyPI, so it is likely now,
> >> after the PEP is accepted, it will be implemented in months rather than
> >> years. And once implemented, the ASF will be able to claim the "apache-"
> >> ownership for PyPI packages.
> >>
> >> This means that the ASF's expectation that Python Packages are named
> with
> >> "apache-" prefix will be not only practical, but also enforceable
> (nobody
> >> else will be able to publish packages with "apache-" prefix. It will
> make
> >> our lives easier to remove anyone who has already done this. We will
> only
> >> have to prove **ONCE** that our organisation - managed by Infra - has
> the
> >> right to use the "apache-" prefix. Then, all cases where someone already
> >> uses an "apache-" package will be much faster - almost automatic—to
> process
> >> following PEP-541 (https://peps.python.org/pep-0541/).
> >>
> >> Currently, it currently takes months to remove someone who is using a
> name
> >> we would like to use. Recent example
> >> https://github.com/pypi/support/issues/10716
> >>
> >> *What does it mean for Infra and Tooling?*
> >>
> >> For now - just awareness.
> >>
> >> If Infra prioritizes it, action will likely be needed in a few months,
> once
> >> the implementation is completed and released in PyPI. We should start
> the
> >> process of;
> >>
> >> a) Requesting the Infra-managed organization to get "apache-" prefix
> >> exclusivity
> >> b) Moving all ASF projects that use PyPI to the new organisation
> >> c) Starting a process to "boot" all non-apache projects using the
> "apache-"
> >> prefix, requiring them to use other names and allowing us to take over
> >> management of the existing projects (basically disabling them)
> >> d) That will also allow connecting Apache Trusted Releases with Trusted
> >> Publishing for the organization and enable all our Python projects to
> use
> >> trusted publishing.
> >>
> >> For incubator - it means that the "apache-" rule will finally be
> >> enforceable and we will always be able to choose the right package name
> and
> >> make sure it will not be taken by others - either maliciously or
> >> accidentally - for any new projects we incubate.
> >>
> >> I am happy to help in my volunteer capacity with all of these efforts,
> >> including leading the move of moving all 200+ Airflow projects to the
> new
> >> organization.
> >>
> >> This all depends on Infra and Tooling priorities, so I am letting you
> know
> >> early so you can decide on priorities and plan accordingly.
> >>
> >> Happy to answer any questions there.
> >>
> >> J.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Jarek Potiuk <ja...@potiuk.com>.
> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] be forced to rename to apache-opendal?
I think it will really depend on the ASF's policies (if someone wants
to make it a mandatory policy). I personally consider it something
that will allow the ASF to prevent "apache-*" from being "hijacked" by
others, not the other way round.
The "Implicit namespace" concept refers more to the fact that in
"apache-NNNN" (or any other prefix), PyPI will be able to derive the
implicit namespace as "apache" and manage it under the organisation
that "owns" it.
But in general—no. In this case "opendal" is both the name in PyPI
**and** name in `pyproject.toml`.toml - they are the same. But if the
Opendal PMC wants to do this—even voluntarily, and even today —it's
entirely possible to make a fairly transparent redirection if desired.
We've done this several times in the past. It's generally enough to
publish a new version of the "empty" opendal package that has
"apache-opendal" as a dependency—this can provide backward
compatibility. So you would have to have the pipeline where you build
the "empty" package and publish it alongside the "apache-opendal" one.
J.
On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
>
> Hi Jarek,
>
> Thanks for your effort in moving this forward!
>
> I have one question:
>
> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] forcely renamed to apache-opendal?
>
> [1] https://pypi.org/project/opendal/
>
> That is, the name "implicit namespaces" seems to imply that the exclusive "apache-" prefix is optional, i.e, there is some auto-prefix logic.
>
> If that is the case, users may still use "opendal = ..." in pyproject.toml and lock the dependency to apache-opendal correctly. Or I understand it wrong?
>
> BTW, the recipients have both public and private mailing lists; I think it would be better to stay in public and only keep the private ones in bcc.
>
> Best,
> tison.
>
>
> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
>>
>> Hello Dear infrastructure team and tooling,
>>
>> I would like to let you know that yesterday, finally, after about 2 years
>> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
>> the new council finally accepted "PEP-752 Implicit namespaces for package
>> repositories," which I co-authored.
>>
>> https://github.com/python/peps/pull/5009
>>
>> *What does this mean for the ASF and PMCs ?*
>>
>> There is a reference implementation of it for PyPI, so it is likely now,
>> after the PEP is accepted, it will be implemented in months rather than
>> years. And once implemented, the ASF will be able to claim the "apache-"
>> ownership for PyPI packages.
>>
>> This means that the ASF's expectation that Python Packages are named with
>> "apache-" prefix will be not only practical, but also enforceable (nobody
>> else will be able to publish packages with "apache-" prefix. It will make
>> our lives easier to remove anyone who has already done this. We will only
>> have to prove **ONCE** that our organisation - managed by Infra - has the
>> right to use the "apache-" prefix. Then, all cases where someone already
>> uses an "apache-" package will be much faster - almost automatic—to process
>> following PEP-541 (https://peps.python.org/pep-0541/).
>>
>> Currently, it currently takes months to remove someone who is using a name
>> we would like to use. Recent example
>> https://github.com/pypi/support/issues/10716
>>
>> *What does it mean for Infra and Tooling?*
>>
>> For now - just awareness.
>>
>> If Infra prioritizes it, action will likely be needed in a few months, once
>> the implementation is completed and released in PyPI. We should start the
>> process of;
>>
>> a) Requesting the Infra-managed organization to get "apache-" prefix
>> exclusivity
>> b) Moving all ASF projects that use PyPI to the new organisation
>> c) Starting a process to "boot" all non-apache projects using the "apache-"
>> prefix, requiring them to use other names and allowing us to take over
>> management of the existing projects (basically disabling them)
>> d) That will also allow connecting Apache Trusted Releases with Trusted
>> Publishing for the organization and enable all our Python projects to use
>> trusted publishing.
>>
>> For incubator - it means that the "apache-" rule will finally be
>> enforceable and we will always be able to choose the right package name and
>> make sure it will not be taken by others - either maliciously or
>> accidentally - for any new projects we incubate.
>>
>> I am happy to help in my volunteer capacity with all of these efforts,
>> including leading the move of moving all 200+ Airflow projects to the new
>> organization.
>>
>> This all depends on Infra and Tooling priorities, so I am letting you know
>> early so you can decide on priorities and plan accordingly.
>>
>> Happy to answer any questions there.
>>
>> J.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by Jarek Potiuk <ja...@potiuk.com>.
> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] be forced to rename to apache-opendal?
I think it will really depend on the ASF's policies (if someone wants
to make it a mandatory policy). I personally consider it something
that will allow the ASF to prevent "apache-*" from being "hijacked" by
others, not the other way round.
The "Implicit namespace" concept refers more to the fact that in
"apache-NNNN" (or any other prefix), PyPI will be able to derive the
implicit namespace as "apache" and manage it under the organisation
that "owns" it.
But in general—no. In this case "opendal" is both the name in PyPI
**and** name in `pyproject.toml`.toml - they are the same. But if the
Opendal PMC wants to do this—even voluntarily, and even today —it's
entirely possible to make a fairly transparent redirection if desired.
We've done this several times in the past. It's generally enough to
publish a new version of the "empty" opendal package that has
"apache-opendal" as a dependency—this can provide backward
compatibility. So you would have to have the pipeline where you build
the "empty" package and publish it alongside the "apache-opendal" one.
J.
On Tue, Jun 30, 2026 at 5:09 PM tison <wa...@gmail.com> wrote:
>
> Hi Jarek,
>
> Thanks for your effort in moving this forward!
>
> I have one question:
>
> By owning the "apache-" prefix exclusivity, will existing ASF projects like opendal [1] forcely renamed to apache-opendal?
>
> [1] https://pypi.org/project/opendal/
>
> That is, the name "implicit namespaces" seems to imply that the exclusive "apache-" prefix is optional, i.e, there is some auto-prefix logic.
>
> If that is the case, users may still use "opendal = ..." in pyproject.toml and lock the dependency to apache-opendal correctly. Or I understand it wrong?
>
> BTW, the recipients have both public and private mailing lists; I think it would be better to stay in public and only keep the private ones in bcc.
>
> Best,
> tison.
>
>
> Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
>>
>> Hello Dear infrastructure team and tooling,
>>
>> I would like to let you know that yesterday, finally, after about 2 years
>> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
>> the new council finally accepted "PEP-752 Implicit namespaces for package
>> repositories," which I co-authored.
>>
>> https://github.com/python/peps/pull/5009
>>
>> *What does this mean for the ASF and PMCs ?*
>>
>> There is a reference implementation of it for PyPI, so it is likely now,
>> after the PEP is accepted, it will be implemented in months rather than
>> years. And once implemented, the ASF will be able to claim the "apache-"
>> ownership for PyPI packages.
>>
>> This means that the ASF's expectation that Python Packages are named with
>> "apache-" prefix will be not only practical, but also enforceable (nobody
>> else will be able to publish packages with "apache-" prefix. It will make
>> our lives easier to remove anyone who has already done this. We will only
>> have to prove **ONCE** that our organisation - managed by Infra - has the
>> right to use the "apache-" prefix. Then, all cases where someone already
>> uses an "apache-" package will be much faster - almost automatic—to process
>> following PEP-541 (https://peps.python.org/pep-0541/).
>>
>> Currently, it currently takes months to remove someone who is using a name
>> we would like to use. Recent example
>> https://github.com/pypi/support/issues/10716
>>
>> *What does it mean for Infra and Tooling?*
>>
>> For now - just awareness.
>>
>> If Infra prioritizes it, action will likely be needed in a few months, once
>> the implementation is completed and released in PyPI. We should start the
>> process of;
>>
>> a) Requesting the Infra-managed organization to get "apache-" prefix
>> exclusivity
>> b) Moving all ASF projects that use PyPI to the new organisation
>> c) Starting a process to "boot" all non-apache projects using the "apache-"
>> prefix, requiring them to use other names and allowing us to take over
>> management of the existing projects (basically disabling them)
>> d) That will also allow connecting Apache Trusted Releases with Trusted
>> Publishing for the organization and enable all our Python projects to use
>> trusted publishing.
>>
>> For incubator - it means that the "apache-" rule will finally be
>> enforceable and we will always be able to choose the right package name and
>> make sure it will not be taken by others - either maliciously or
>> accidentally - for any new projects we incubate.
>>
>> I am happy to help in my volunteer capacity with all of these efforts,
>> including leading the move of moving all 200+ Airflow projects to the new
>> organization.
>>
>> This all depends on Infra and Tooling priorities, so I am letting you know
>> early so you can decide on priorities and plan accordingly.
>>
>> Happy to answer any questions there.
>>
>> J.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by tison <wa...@gmail.com>.
Hi Jarek,
Thanks for your effort in moving this forward!
I have one question:
By owning the "apache-" prefix exclusivity, will existing ASF projects like
opendal [1] forcely renamed to apache-opendal?
[1] https://pypi.org/project/opendal/
That is, the name "implicit namespaces" seems to imply that the
exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
logic.
If that is the case, users may still use "opendal = ..." in pyproject.toml
and lock the dependency to apache-opendal correctly. Or I understand it
wrong?
BTW, the recipients have both public and private mailing lists; I think it
would be better to stay in public and only keep the private ones in bcc.
Best,
tison.
Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> Hello Dear infrastructure team and tooling,
>
> I would like to let you know that yesterday, finally, after about 2 years
> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
> the new council finally accepted "PEP-752 Implicit namespaces for package
> repositories," which I co-authored.
>
> https://github.com/python/peps/pull/5009
>
> *What does this mean for the ASF and PMCs ?*
>
> There is a reference implementation of it for PyPI, so it is likely now,
> after the PEP is accepted, it will be implemented in months rather than
> years. And once implemented, the ASF will be able to claim the "apache-"
> ownership for PyPI packages.
>
> This means that the ASF's expectation that Python Packages are named with
> "apache-" prefix will be not only practical, but also enforceable (nobody
> else will be able to publish packages with "apache-" prefix. It will make
> our lives easier to remove anyone who has already done this. We will only
> have to prove **ONCE** that our organisation - managed by Infra - has the
> right to use the "apache-" prefix. Then, all cases where someone already
> uses an "apache-" package will be much faster - almost automatic—to process
> following PEP-541 (https://peps.python.org/pep-0541/).
>
> Currently, it currently takes months to remove someone who is using a name
> we would like to use. Recent example
> https://github.com/pypi/support/issues/10716
>
> *What does it mean for Infra and Tooling?*
>
> For now - just awareness.
>
> If Infra prioritizes it, action will likely be needed in a few months, once
> the implementation is completed and released in PyPI. We should start the
> process of;
>
> a) Requesting the Infra-managed organization to get "apache-" prefix
> exclusivity
> b) Moving all ASF projects that use PyPI to the new organisation
> c) Starting a process to "boot" all non-apache projects using the "apache-"
> prefix, requiring them to use other names and allowing us to take over
> management of the existing projects (basically disabling them)
> d) That will also allow connecting Apache Trusted Releases with Trusted
> Publishing for the organization and enable all our Python projects to use
> trusted publishing.
>
> For incubator - it means that the "apache-" rule will finally be
> enforceable and we will always be able to choose the right package name and
> make sure it will not be taken by others - either maliciously or
> accidentally - for any new projects we incubate.
>
> I am happy to help in my volunteer capacity with all of these efforts,
> including leading the move of moving all 200+ Airflow projects to the new
> organization.
>
> This all depends on Infra and Tooling priorities, so I am letting you know
> early so you can decide on priorities and plan accordingly.
>
> Happy to answer any questions there.
>
> J.
>
Re: Implicit namespaces for package repositories (PyPI) accepted
Posted by tison <wa...@gmail.com>.
Hi Jarek,
Thanks for your effort in moving this forward!
I have one question:
By owning the "apache-" prefix exclusivity, will existing ASF projects like
opendal [1] forcely renamed to apache-opendal?
[1] https://pypi.org/project/opendal/
That is, the name "implicit namespaces" seems to imply that the
exclusive "apache-" prefix is optional, i.e, there is some auto-prefix
logic.
If that is the case, users may still use "opendal = ..." in pyproject.toml
and lock the dependency to apache-opendal correctly. Or I understand it
wrong?
BTW, the recipients have both public and private mailing lists; I think it
would be better to stay in public and only keep the private ones in bcc.
Best,
tison.
Jarek Potiuk <ja...@potiuk.com> 于2026年6月30日周二 20:30写道：
> Hello Dear infrastructure team and tooling,
>
> I would like to let you know that yesterday, finally, after about 2 years
> of back-and-forth and PEP-772 changing how the Packaging Team accepts PEPs,
> the new council finally accepted "PEP-752 Implicit namespaces for package
> repositories," which I co-authored.
>
> https://github.com/python/peps/pull/5009
>
> *What does this mean for the ASF and PMCs ?*
>
> There is a reference implementation of it for PyPI, so it is likely now,
> after the PEP is accepted, it will be implemented in months rather than
> years. And once implemented, the ASF will be able to claim the "apache-"
> ownership for PyPI packages.
>
> This means that the ASF's expectation that Python Packages are named with
> "apache-" prefix will be not only practical, but also enforceable (nobody
> else will be able to publish packages with "apache-" prefix. It will make
> our lives easier to remove anyone who has already done this. We will only
> have to prove **ONCE** that our organisation - managed by Infra - has the
> right to use the "apache-" prefix. Then, all cases where someone already
> uses an "apache-" package will be much faster - almost automatic—to process
> following PEP-541 (https://peps.python.org/pep-0541/).
>
> Currently, it currently takes months to remove someone who is using a name
> we would like to use. Recent example
> https://github.com/pypi/support/issues/10716
>
> *What does it mean for Infra and Tooling?*
>
> For now - just awareness.
>
> If Infra prioritizes it, action will likely be needed in a few months, once
> the implementation is completed and released in PyPI. We should start the
> process of;
>
> a) Requesting the Infra-managed organization to get "apache-" prefix
> exclusivity
> b) Moving all ASF projects that use PyPI to the new organisation
> c) Starting a process to "boot" all non-apache projects using the "apache-"
> prefix, requiring them to use other names and allowing us to take over
> management of the existing projects (basically disabling them)
> d) That will also allow connecting Apache Trusted Releases with Trusted
> Publishing for the organization and enable all our Python projects to use
> trusted publishing.
>
> For incubator - it means that the "apache-" rule will finally be
> enforceable and we will always be able to choose the right package name and
> make sure it will not be taken by others - either maliciously or
> accidentally - for any new projects we incubate.
>
> I am happy to help in my volunteer capacity with all of these efforts,
> including leading the move of moving all 200+ Airflow projects to the new
> organization.
>
> This all depends on Infra and Tooling priorities, so I am letting you know
> early so you can decide on priorities and plan accordingly.
>
> Happy to answer any questions there.
>
> J.
>