> 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]
