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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 于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: [email protected] For additional commands, e-mail: [email protected]
