Finally! Good work pushing this through Jarek On Tue, 30 Jun 2026 at 21:01, Dave Fisher <[email protected]> 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 <[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. > >
