The 'cqlsh' package has been maintained at pypi.org since 2013, see https://pypi.org/project/cqlsh/#history. There is a solid 10 year history of support and interest in the Python package distribution for cqlsh and it has 11K/downloads per week.
A few additions to Jeff's comments: - The 'cqlsh' package has one primary file which is all of 36 lines, *setup.cfg*. The suggestion is to 1) move this file into the Apache Cassandra repository together with a README.md, and 2) add pypi as a distribution target for new Apache Cassandra releases of cqlsh. - As it exists today, the 'cqlsh' project is really just a stub which exists outside of Apache Cassandra to package cqlsh for distribution onto pypi.org. - For Windows clients (and yes, there are lots), 'pip install cqlsh' is the best way to run cqlsh on Windows. On Thu, Jul 6, 2023 at 9:50 PM guo Maxwell <cclive1...@gmail.com> wrote: > Hi ： > First of all, thank you very much for your work. I have a question: what > is your long-term evolution plan for this project? How to achieve long-term > continuous maintenance of this project? I have encountered some situations > where some people's work is related to a certain project, and then they may > have time to maintain, but once they change jobs, they may not have enough > time to do this. Besides, can you share more about the code management > mechanism? > > Jeff Widman <j...@jeffwidman.com> 于2023年7月7日周五 08:56写道： > >> Myself and Brad Schoening currently maintain >> https://pypi.org/project/cqlsh/ which repackages CQLSH that ships with >> every Cassandra release. >> >> This way: >> >> - anyone who wants a lightweight client to talk to a remote cassandra >> can simply `pip install cqlsh` without having to download the full >> cassandra source, unzip it, etc. >> - it's very easy for folks to use it as scaffolding in their python >> scripts/tooling since they can simply include it in the list of their >> required dependencies. >> >> We currently handle the packaging by waiting for a release, then manually >> copy/pasting the code out of the cassandra source tree into >> https://github.com/jeffwidman/cqlsh which has some additional >> build/python package configuration files, then using standard >> python tooling to publish to PyPI. >> >> Given that our project is simply a build/packaging project, I wanted to >> start a conversation about upstreaming this into core Cassandra. I realize >> that Cassandra has no interest in maintaining lots of build targets... but >> given that cqlsh is written in Python and publishing to PyPI enables DBA's >> to share more complicated tooling built on top of it this seems like a >> natural fit for core cassandra rather than a standalone project. >> >> Goal: >> When a Cassandra release happens, the build/release process automatically >> publishes cqlsh to https://pypi.org/project/cqlsh/. >> >> Non-Goal: This is _not_ about having cassandra itself rely on PyPI. There >> was some initial chatter about that in >> https://issues.apache.org/jira/browse/CASSANDRA-18654, but that adds a >> lot of complexity, and I'm honestly not sure it's a great idea. Even if >> folks later want to go that route, the first hurdle is publishing to PyPI, >> so for now let's keep the scope of the discussion limited to treating PyPI >> purely as a release target, and not as an ingredient to a release. >> >> From an implementation perspective, this should be very straightforward. >> We don't have any differences from the CQLSH source that's in cassandra, >> instead we point folks to make changes to cqlsh in the Cassandra source. In >> fact we've made multiple contributions back to `cqlsh` ourselves and have >> drastically cleaned up the code: >> https://github.com/search?q=repo%3Aapache%2Fcassandra%20is%3Apr%20author%3Ajeffwidman%20author%3Abschoening&type=pullrequests. >> So the only real change is adding the package config files and the build / >> release pipeline. >> >> We realize the Cassandra team isn't python/PyPI experts, so we'd be more >> than happy to help wire this up and maintain it. I am also a maintainer of >> kazoo and kafka-python which are both popular python clients for other >> distributed databases. So I'm very familiar with open source, python, and >> distributed databases. >> >> My one hesitation around this discussion is that I'm a little concerned >> that we might lose the nimbleness we've currently got from having a >> separate project. Ie, if something is screwed up on PyPI / the build >> process, we can quickly get it fixed and get a new release out so that >> users aren't blocked. Would it be possible as part of this process to >> continue that myself/Brad had commit rights to the build process for PyPI? >> To be clear, I'm not asking for commit rights to the Java code or anything >> outside of Python, I just want to be sure that if we go to the trouble of >> working with you to upstream this that there's a commitment from Cassandra >> to keeping this build working, or to letting us be able to fix the build. >> Otherwise there's no point in upstreaming it only for it to go unmaintained >> leaving us looking on helplessly from the sidelines. I'm very flexible here >> on the solution. >> >> Thoughts? >> >> -- >> >> *Jeff Widman* >> jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265) >> <>< >> > > > -- > you are the apple of my eye ! >
