Using test.pypi.org for nightly release sounds great! Thanks for the suggestion!
Yufei On Wed, Nov 19, 2025 at 2:54 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi JB, > > Good point about test.pypi.org! +1 to using it for staging. > > Cheers, > Dmitri. > > On Wed, Nov 19, 2025 at 5:50 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Oh, I have a proposal for nightly builds: nightly builds should be > > pushed to test.pypi.org. > > > > Thanks to test.pypi.org, it's clearly stated that it's nightly builds > > (not release). > > > > It's also something we can use to stage artifacts during release votes. > > > > For instance, see https://test.pypi.org/project/opendal/. > > > > Regards > > JB > > > > On Wed, Nov 19, 2025 at 12:07 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > Hi Yufei, > > > > > > Regarding the proposed nightly build, I agree with your suggestion and > > > am completely in favor, provided all legal aspects are fully vetted > > > and compliant (it's blocker for publication, as I said in the Python > > > CLI thread). > > > > > > I would be happy to volunteer to assist with the necessary legal > > > checks for the MCP server. > > > > > > Thanks! > > > > > > Regards, > > > JB > > > > > > On Wed, Nov 19, 2025 at 9:59 AM Yufei Gu <[email protected]> wrote: > > > > > > > > Hi everyone, > > > > > > > > Thanks for chiming in on the package naming discussion and appreciate > > all > > > > the feedback so far. I’d like to leave a bit more time for others to > > weigh > > > > in as well, in case there are additional concerns or suggestions. > > > > > > > > In parallel, here’s the proposed next step so we can keep making > > progress: > > > > Publish a nightly build to PyPI as part of our GitHub CI workflow. > This > > > > will help us validate the packaging structure early, catch issues > > sooner, > > > > and give contributors an easy way to try the MCP server from PyPI > > before > > > > the first official release. > > > > > > > > Please feel free to continue the discussion. > > > > > > > > Yufei > > > > > > > > > > > > On Wed, Nov 19, 2025 at 8:14 AM Dmitri Bourlatchkov < > [email protected]> > > > > wrote: > > > > > > > > > Hi Yufei, > > > > > > > > > > The name "apache-polaris-mcp" LGTM. > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Tue, Nov 18, 2025 at 1:34 PM Yufei Gu <[email protected]> > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > I’d like to propose standardizing the PyPI package name for the > new > > > > > Polaris > > > > > > MCP server as *apache-polaris-mcp.* > > > > > > > > > > > > This follows the naming conventions used by other Apache projects > > on PyPI > > > > > > (e.g., apache-airflow, apache-beam, apache-libcloud) and matches > > PyPI’s > > > > > > canonical normalization rules. Using the lowercase hyphenated > form > > > > > directly > > > > > > keeps things consistent for users, avoids normalization > surprises, > > and > > > > > > aligns better with ASF branding. > > > > > > > > > > > > This also follows the naming convention we discussed > > > > > > < > https://lists.apache.org/thread/7fnnwdb2rnxmb2tk0yo8jh5mt7s325dx> > > for > > > > > > Polaris CLI tool. A clarification regarding packaging: > > > > > > The MCP server package cannot be combined with the Polaris CLI > > tools > > > > > > package, even if we wanted to. The two components live in > different > > > > > > repositories and use separate pyproject.toml configurations. > > Because of > > > > > > this, there is no clean or practical way to publish them as a > > single PyPI > > > > > > distribution without major restructuring(e.g., moving MCP server > > to the > > > > > > main repo). > > > > > > > > > > > > If there are concerns or alternative suggestions, please reply. > > > > > > > > > > > > Thanks, > > > > > > Yufei > > > > > > > > > > > > > >
