[
https://issues.apache.org/jira/browse/CASSANDRA-18654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740777#comment-17740777
]
Jeff Widman edited comment on CASSANDRA-18654 at 7/6/23 7:55 PM:
-----------------------------------------------------------------
> How will we handle that cqlsh is tied to the server version it ships with?
So far, history has shown the coupling isn't as tight as you might think. I can
use latest `cqlsh` off PyPI with older Cassandra's just fine, I just can't use
certain cqlsh features.
> I should just unzip it and run Cassandra and I should be able to interact
> with that.
Absolutely, not trying to "force" anyone to use PyPI, cqlsh would still ship
with Cassandra source and can be used without referencing PyPI at all.
> yeah, I just mean that a particular Cassandra release would "reference" a
> particular release in Pypi.
I mean, I guess you could do that... My assumption is Cassandra would still use
it's local cqlsh most of the time... trying to use PyPI would be nice, but as
you point out, it'll get a lot more complicated quickly. I think simpler is to
say "we also publish to PyPI, which you can use as a remote client if you just
need cqlsh w/o pulling in the full cassandra source."
> There would need to be separate Pypi projects, per Cassandra major branch.
Why? I'd expect that publishing to PyPI only happens upon release, and at that
point you would just push up say 4.0.1 and also 4.1.1, all to the same PyPI
project. I don't understand why it'd need separate projects?
If you do want to say "even for local / dev cassandra development we want to
use python packages", then probably best to use
https://pip.pypa.io/en/stable/topics/local-project-installs/#editable-installs
with the local copy of the python source and not hit PyPI. Only actual releases
would use PyPI... but again, for users there's network firewall issues,
etc--easier to keep cassandra self-contained w/o needing PyPI just to run
cqlsh.
I'm trying to solve the opposite problem, of someone who says "I just need
cqlsh to access a remote cassandra, I don't want all that java code too, nor
figuring out how to build, just want `pip install cqlsh / require cqlsh`. In
that case publishing to PyPI only needs to happen when a release happens, and
it can all use the same PyPI project.
was (Author: jeffwidman):
> How will we handle that cqlsh is tied to the server version it ships with?
So far, history has shown the coupling isn't as tight as you might think. I can
use latest `cqlsh` off PyPI with older Cassandra's just fine, I just can't use
certain cqlsh features.
> I should just unzip it and run Cassandra and I should be able to interact
> with that.
Absolutely, not trying to "force" anyone to use PyPI, cqlsh would still ship
with Cassandra source and can be used without referencing PyPI at all.
> yeah, I just mean that a particular Cassandra release would "reference" a
> particular release in Pypi.
I mean, I guess you could do that... My assumption is Cassandra would still use
it's local cqlsh most of the time... trying to use PyPI would be nice, but as
you point out, it'll get a lot more complicated quickly. I think simpler is to
say "we also publish to PyPI, which you can use as a remote client if you just
need cqlsh w/o pulling in the full cassandra source."
> There would need to be separate Pypi projects, per Cassandra major branch.
Why? I'd expect that publishing to PyPI only happens upon release, and at that
point you would just push up say 4.0.1 and also 4.1.1, all to the same PyPI
project. I don't understand why it'd need separate projects?
If you want to use a Python package for local cassandra development, you'd use
https://pip.pypa.io/en/stable/topics/local-project-installs/#editable-installs
with the local copy of the python source.
The PyPI bit is only published when a release happens, and the intent is solely
for folks who want a lightweight client w/o having to download the entire
cassandra source, they can get just the python client with a simple `pip
install cqlsh`.
> Make publishing to https://pypi.org/project/cqlsh/ part of Cassandra core
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-18654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18654
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jeff Widman
> Priority: Normal
>
> Myself and [~bschoeni] currently maintain https://github.com/jeffwidman/cqlsh
> which repackages the CQLSH from Cassandra it into a standalone Python
> package that is published to https://pypi.org/project/cqlsh/ for
> lighter-weight installs.
> Given that our project is simply a build/packaging project, we wanted start a
> conversation about upstreaming this into core Cassandra.
> We don't have any differences from the CQLSH source that's in cassandra,
> instead we point all contributors to contribute back to the Cassandra
> project. 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
> Our goal:
> When a Cassandra release happens, the build/release process automatically
> publishes cqlsh to https://pypi.org/project/cqlsh/
> Benefits:
> - more efficient because we no longer have to manually copy/paste cqlsh
> source around, it'd be automatically done by CI.
> - easier for folks to test python packaging because they could use this
> pipeline to build the core source locally into a python package.
> - reduced bus factor because the PyPI namespace would be under the ownership
> of core Cassandra rather than just Jeff/Brad.
> 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 also realize that Cassandra has no interest in maintaining lots of build
> targets... but given that cqlsh is written in Python and PyPI is the
> cannonical place to publish python packages, this seems like a natural fit
> for core cassandra rather than a standalone project.
> Our one hesitation around this discussion is that we're 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, we aren't asking
> for commit rights to the Java code or anything outside of Python, we 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 and us look on helplessly from
> the sidelines. We're very flexible here on the solution.
> Thoughts?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
