harelba/q

Import error

psychemedia opened this issue · 16 comments

Installing current version on Mac using brew install q:

==> Downloading https://github.com/harelba/q/archive/1.7.1.tar.gz
==> Downloading from https://codeload.github.com/harelba/q/tar.gz/1.7.1

Running q commands gives me an import error:

File "/usr/local/bin/q", line 139
    except ImportError, e:

which is presumably resulting from using an inappropriate version of python? Is this picked up from a path / settable anywhere? If so, what are the Python version requirements?

bitti commented

Works fine for me:

$ brew install q
Updating Homebrew...
==> Auto-updated Homebrew!
[...]
==> Downloading https://github.com/harelba/q/archive/1.7.1.tar.gz
==> Downloading from https://codeload.github.com/harelba/q/tar.gz/1.7.1
######################################################################## 100.0%
🍺  /usr/local/Cellar/q/1.7.1: 4 files, 81.5KB, built in 2 seconds

What does python --version yields for you? I get the system default version Python 2.7.15. Note that q is not Python 3 compatible yet, when I change my virtualenv to a Python 3 environment I get the same error as you. That can be considered a bug, since users of q shouldn't have to care if it's implemented in Python.

@harelba: I suggest to replace the shebang line #!/usr/bin/env python with #!/usr/bin/env python2 till Python 3 compatibility is achieved.

I thought it was a py2/3 issue. (I have Python 3.6.4 :: Anaconda custom (64-bit) leading from my default path; I dumped the default Mac python a long time ago... Which makes me wonder if other things elsewhere are broken if I try to run them!)

bitti commented

What do you mean by "dumped"? Deleted /usr/bin/python? I think Mac OS doesn't really rely on the system Python being available, although there might be a few old obscure scripts which do (like /usr/bin/smtpd.py). There might be some 3rd party apps tough which rely on the system python though.

But I guess by "dumped" you mean you just changed the default path python, since modifying /usr/bin would require disabling the system integrity protection under a recent Mac OS. Indeed I just rechecked and noticed that my Python 2.7.15 is coming from a brew installation, the actual system python in /usr/bin/python is Python 2.7.10. So I have the same situation as you, my default path python is not using the system Python with the difference that it's still a version 2 python.

So if you insist to have Python 3 as a your default python I guess the only option is to either write a wrapper for q which changes the default environment to python 2 or to directly change the shebang line of the /usr/local/bin/q executable (which has the disadvantage of being overwritten on the next brew upgrade when the issue is still not fixed in the next q release).

@bitti would #!...python2 be available on all platforms? If yes, then it might be a great idea.

Anyway, when I have a moment or two, i'll try to finish the make-q-python-3-compatible...

bitti commented

There is no guarantee, but PEP-0394 clearly states

Unix-like software distributions (including systems like Mac OS X and Cygwin) should install the python2 command into the default path whenever a version of the Python 2 interpreter is installed

So even though according to the spec the python binary should point to a python 2 interpreter if available, this can not be expected anymore since quite a while, therefore:

python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3.

On Mac OS I can not see a python2 executable in the default system path /usr/bin though, only a link for python2.7 (which probably gets installed with Xcode). But this could be easily remedied by the Homebrew people by adding a python 2 as dependency for the q package (which then also installs a python2 executable as per spec).

But no matter how we slice and dice it, the current shebang line is broken according to this PEP unless q is python 2 and python 3 compatible (which of course would be the best solution if it could be implemented in a reasonable time).

"Dumped" as in I avoid it and try not to default to it.

On Macs, I think there is an explicit python2 at /usr/local/bin/python2?

bitti commented

The stuff in /usr/local is user installed and not part of the system default installation. In my case it's just a link to a homebrew installed Python, probably in yours too:

$ ll /usr/local/bin/python2
lrwxr-xr-x  1 david  admin  37 Jun 11 17:12 /usr/local/bin/python2@ -> ../Cellar/python@2/2.7.15/bin/python2

I'm running into the same issue.

$ ./q "SELECT c6,COUNT(1) FROM ../examples/exampledatafile GROUP BY c6"
File "./q", line 139
    except ImportError, e:
                      ^
SyntaxError: invalid syntax

$ ../bin/./q "SELECT c6,COUNT(1) FROM exampledatafile GROUP BY c6"
File "../bin/./q", line 139
    except ImportError, e:
                      ^
SyntaxError: invalid syntax

EDIT: this issue doesn't occur with the AUR version.

@Berkmann18 please confirm that your python is indeed 3.x.

Hopefully we'll soon support both python3 and python2, and i'll issue a new version that supports it.

If you wanna hack it for now, and you have python2 installed on your machine as well, you can change the first line in q's executable to #!/usr/bin/env python2 instead of just ...python.

I'll update here when a new version will come out.

@harelba It is indeed.

Hopefully, we'll have a python 3 compatible version soon. Until then, see my workaround above if applicable in your case.

Sorry for the inconvenience.

As a temp fix, if python2 is in your path, can just change /bin/q first line from:

#!/usr/bin/env python

to:

#!/usr/bin/env python2

master is fully python2+3 compatible now. I'll try to issue a new release soon.

I have the same issue with q version 1.7.4 ... Here's a screenshot:

image

@yarongon This is directly related to the fact that you're using python 3. Version 1.7.4 requires python2. See above for a possible workaround if you have python 2 installed in parallel.

The q master branch already contains python2+3 compatibility, and will be released probably in a couple of weeks (requires major changes to the packaging/release process).

Newest release is fully py2/3 compatible, and is packaged in a new way that eliminates the need for dependencies (in linux/windows there's no need even for python itself). These errors should not happen any longer.