Hi folks, Here’s the PR that adds nightly publication support for the MCP server: https://github.com/apache/polaris-tools/pull/86
You can already see the published test package here: https://test.pypi.org/project/apache-polaris-mcp/ To try it locally: python3 -m venv .venv source .venv/bin/activate pip install --index-url https://test.pypi.org/simple/ \ --extra-index-url https://pypi.org/simple \ apache-polaris-mcp uv run polaris-mcp # or configure it via your LLM chat tool The CI workflow for automated nightly publishing is still in progress. I’ll file a follow-up PR for that. Yufei On Thu, Nov 20, 2025 at 4:09 PM Yufei Gu <[email protected]> wrote: > 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 >> > > > > > >> > > > > >> > >> >
