Super cool! Thanks Yufei. Here's a one-liner with uvx ``` uvx --index https://test.pypi.org/simple/ \ --index-strategy unsafe-best-match \ --prerelease=if-necessary \ --from apache-polaris-mcp \ polaris-mcp ```
Best, Kevin Liu On Thu, Jan 8, 2026 at 3:53 PM Yufei Gu <[email protected]> wrote: > The MCP Server Nightly publish was done. You can find the first > publish(triggered manually for the first time) 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 > > > Thanks a lot for the review, Jonas and Yong! > > Yufei > > > On Tue, Dec 30, 2025 at 12:39 PM Yufei Gu <[email protected]> wrote: > > > Hi everyone, here is a PR to publish it nightly, > > https://github.com/apache/polaris-tools/pull/119. Please take a look. > > Thanks! > > > > Yufei > > > > > > On Mon, Dec 1, 2025 at 3:29 PM Yufei Gu <[email protected]> wrote: > > > >> 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 > >>>> > > > > > > >>>> > > > > > >>>> > > >>>> > >>> >
