ImportError: No module named cqlsh on 6.0.1

[Nx5]

Hey,
using python 2.7.18, we've been running 6.0.0 in circleci with success,
but since 6.0.1 we're getting an error:

circleci@ff66acb3ef0c:~$ cqlsh
Traceback (most recent call last):
  File "/home/circleci/.pyenv/versions/2.7.18/bin/cqlsh", line 6, in <module>
    from cqlsh.__main__ import main
  File "/home/circleci/.pyenv/versions/2.7.18/lib/python2.7/site-packages/cqlsh/__main__.py", line 3, in <module>
    from cqlsh.cqlsh import main as cqlsh_main
ImportError: No module named cqlsh

[bschoening]

Hi,

Python 2.7.x reached End of Life over two years ago on January 1, 2020. No new bug reports, fixes, or changes will be made to Python 2, and Python 2 is no longer supported by its authors. This includes security issues which will not be patched, of which there are already a few reported. See the full statement at https://www.python.org/doc/sunset-python-2.

One of the import changes in Python 3 was to module structure, and while I'm not certain it can't work with the new module structure, I think it's perhaps unlikely.

Are you able to continue to use the 6.0.0 version of CQLSH with circleci?

[mccaig]

Hi,

I have the same issue as @Nx5, the most recent release was a breaking change for a number of our tools. I understand that Python 2 is EOL, and I'm at work on a workaround. Just wanted to chime in here as it could be an issue for others.

[jeffwidman]

My apologies, I didn't think to test on python 2, as I haven't used it in over a year. Shows that we need some sort of basic CI... I filed #12 for that.

Let's do this:

1. This is a broken release since it incorrectly advertises support for python 2, so the first thing is to yank the release. I don't have the rights to do that, so I pinged @aboudreault and hopefully he can do that later today. That should stop the bleeding for folks.
2. Let's investigate to see if there's an easy way to tweak the changes in Modularize 'cqlsh' for use in python imports and better support for Windows installations #7 to be py2 compatible. If anyone has suggestions, please chime in or open a PR.
3. if there's no easy solution for py2 compatibility, then we will drop py2 compatibility and cut a new release. Folks who are still on python 2 will continue to use 6.0.0 as it's a stable release for them, and pip is smart enough to ignore the newer versions since they won't advertise py2 support.

The other option is to revert #7 for now, but I support the goals of making this easy to use as both a library and an executable. Plus it's def more convenient for Windows users.

I expect py2 compatibility to become less and less of an issue over time as many folks switch over to python 3, although I recognize since this particular lib is often installed purely as an executable, not everyone has migrated to newer Linuxes that support python 3.

That said, if there's a relatively straightforward way to retain py2 support, then that's going to be the best solution.

[jeffwidman]

The 6.0.1 release has been yanked, so closing this ticket for now.

We'll use #13 to track fixing the underlying issue before the next release.