We Keep Coding

Dockerized Django tests only look at first $PATH location

I'm running a Django test suite in a Docker container, and some of these tests use a program I've had to apt-get install (wkhtmltopdf). Now I can see that it's been installed correctly:
$ wkhtmltopdf --version
wkhtmltopdf 0.12.5
but for some reason the Django test can't use it. The installation location is definitely on my $PATH (third to last element):
$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ find / -name wkhtmltopdf
/usr/bin/wkhtmltopdf
However when I run tests I get a stack trace ending in:
OSError: No wkhtmltopdf executable found: "/usr/local/bin/wkhtmltopdf"
If this file exists please check that this process can read it. Otherwise please install wkhtmltopdf - https://github.com/JazzCore/python-pdfkit/wiki/Installing-wkhtmltopdf
Now it's absolutely correct that there is no /usr/local/bin/wkhtmltopdf, because it got installed elsewhere (/usr/bin/) but both those locations are on $PATH.
I've tried moving /usr/bin/ to the start of $PATH, but I then get the error:
Traceback (most recent call last):
File "./manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management
presumably because it's now looking in /usr/bin/ for django when it's actually in usr/local/bin/, which is no longer the first location on $PATH.
I'm not sure if the problem is a Docker one, a Django one, a testing one, or just me misunderstanding one or more things going on here.

So it turns out that the project is using pdfkit as a wrapper for wkhtmltopdf, which includes setting the wkhtmltopdf path directly:
config = pdfkit.configuration(wkhtmltopdf=settings.WKHTMLTOPDF_BIN)
which after a quick look at the Django settings file was set to:
WKHTMLTOPDF_BIN = '/usr/local/bin/wkhtmltopdf'
Mystery solved! The fix in this case was to simply set it to the actual path desired (/usr/bin/wkhtmltopdf).

Mac gcloud install ImportError: No module named __future__

When installing gcloud for mac I get this error when I run the install.sh command according to docs here:
Traceback (most recent call last):
File "/path_to_unzipped_file/google-cloud-sdk/bin/bootstrapping/install.py", line 8, in <module>
from __future__ import absolute_import
I poked through and echoed out some stuff in the install shell script. It is setting the environment variables correctly (pointing to my default python installation, pointing to the correct location of the gcloud SDK).
If I just enter the python interpreter (using the same default python that the install script points to when running install.py) I can import the module just fine:
>>> from __future__ import absolute_import
>>>
Only other information worth noting is my default python setup is a virtual environment that I create from python 2.7.15 installed through brew. The virtual environment python bin is first in my PATH so python and python2 and python2.7 all invoke the correct binary. I've had no other issues installing packages on this setup so far.
If I echo the final line of the install.sh script that calls the install.py script it shows /path_to_virtualenv/bin/python -S /path_to_unzipped_file/google-cloud-sdk/bin/bootstrapping/install.py which is the correct python. Or am I missing something?

The script uses the -S command-line switch, which disables loading the site module on start-up.
However, it is a custom dedicated site module installed in a virtualenv that makes a virtualenv work. As such, the -S switch and virtualenvs are incompatible, with -S set fundamental imports such as from __future__ break down entirely.
You can either remove the -S switch from the install.bat command or use a wrapper script to strip it from the command line as you call your real virtualenv Python.

I had the error below when trying to run gcloud commands.
File "/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/lib/gcloud.py", line 20, in <module>
from __future__ import absolute_import
ImportError: No module named __future__
If you have your virtualenv sourced automatically you can specify the environment variable CLOUDSDK_PYTHON i.e. set -x CLOUDSDK_PYTHON /usr/bin/python to not use the virtualenv python.

In google-cloud-sdk/install.sh go to last line, remove variable $CLOUDSDK_PYTHON_ARGS as below.
"$CLOUDSDK_PYTHON" $CLOUDSDK_PYTHON_ARGS "${CLOUDSDK_ROOT_DIR}/bin/bootstrapping/install.py" "$#"
"$CLOUDSDK_PYTHON" "${CLOUDSDK_ROOT_DIR}/bin/bootstrapping/install.py" "$#"

Sublime text & Linux-KDE. System locales is set to a value that can not handle non-ASCII characters

I'm getting this error when I open ST3. Package control is not working.
Package Control Your system's local is set to a value that can not
handle non ASCII characters. Package Control can not properly work
unless this is fixed.
On Linux, please reference your distribution's docs for on properly
setting the LANG environmental variable. As a temporary work-around,
you can launch Sublime Text from the terminal with:
LANG=en_US.UTF-8 sublime_text
The termporary workaround doesn't work. Also, when I write 'locale' in the terminal I get:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_EC.UTF-8
LANGUAGE=en:es:en
LC_CTYPE="en_EC.UTF-8"
LC_NUMERIC=en_EC.UTF-8
LC_TIME=en_EC.UTF-8
LC_COLLATE="en_EC.UTF-8"
LC_MONETARY=en_EC.UTF-8
LC_MESSAGES="en_EC.UTF-8"
LC_PAPER=en_EC.UTF-8
LC_NAME=en_EC.UTF-8
LC_ADDRESS=en_EC.UTF-8
LC_TELEPHONE=en_EC.UTF-8
LC_MEASUREMENT=en_EC.UTF-8
LC_IDENTIFICATION=en_EC.UTF-8
LC_ALL=
Please help. I'm on Ubuntu+KDE, Im coding blindly now with no sublime packages installed.

I had the same issue while attempting to install Package Control on Ubuntu 14.04 LTS via the prescribed method within Chroot of ChromeOS, Sublime Text Build 3083.
A sensible solution for this problem exists in a duplicate of this issue here: https://askubuntu.com/a/440341/200027
The solution involves adding "bash -c "LANG=en_US.UTF-8 /opt/sublime_text/sublime_text" to the appropriate Exec lines of Sublime's .desktop unity launch file located at /usr/applications/share/sublime_text.desktop as follows:
[Desktop Entry]
Version=1.0
Type=Application
Name=Sublime Text
GenericName=Text Editor
Comment=Sophisticated text editor for code, markup and prose
Exec=bash -c "LANG=en_US.UTF-8 /opt/sublime_text/sublime_text %F"
Terminal=false
MimeType=text/plain;
Icon=sublime-text
Categories=TextEditor;Development;
StartupNotify=true
Actions=Window;Document;
[Desktop Action Window]
Name=New Window
Exec=bash -c "LANG=en_US.UTF-8/opt/sublime_text/sublime_text -n"
OnlyShowIn=Unity;
[Desktop Action Document]
Name=New File
Exec= bash -c "LANG=en_US.UTF-8/opt/sublime_text/sublime_text --command new_file"
OnlyShowIn=Unity;
Note that you will need sudo to edit that desktop launch file.

How to fix locale issue in Red Hat distro?

I'm having a strange problem today in my RHEL system. My python script is returning:
>>> locale.setlocale(locale.LC_ALL, '')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/locale.py", line 513, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
WHen I run...
$ locale
The ouput is...
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
...
I have been trying many suggestions but none of them solved my issue yet.
For example:
Reinstall glibc-common.
Export LC_ALL as environment variable into ~/.bashrc.
Change the file /etc/sysconfig/i18n'.
locale-gen does not exists in RHEL.
Does anyone has a good suggestion to solve my issue. Remembering that I'm using RHEL and not Ubuntu (there are many tutorials about locale issues and Ubuntu).

Add this to your /etc/environment:
LC_ALL=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
Then logout and login to shell again and try executing your commands.

In my case it was iTerm setting the locale variables automatically. I fixed it by going to the iTerm menu and then
Preferences ... > Profiles > "select your profile" > Terminal > uncheck "Set locale variables automatically"

The addition to /etc/environment of following variables fixed my issue:
LC_ALL=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
Good answer above.

Why is "sys.argv" not available in Sublime API?

This question was already asked on Sublime Forum, but it seems no one can answer it. Maybe you can?
I've got the same issue on Windows 7 and 8, Sublime 2.0.1 x86 version:
Traceback (most recent call last):
File "./sublime_plugin.py", line 362, in run_
File "./myTestPlugin.py", line 8, in run
AttributeError: 'module' object has no attribute 'argv'

Because sublime plugins are not scripts. There is no command line, so there are no command line arguments to parse.
Python, in Sublime, is embedded, and for embedded python code to have sys.argv set, Sublime would have to set the arguments explicitly. See Intro to embedding Python.
If you feel strongly about this, you'd have to make a case with the Sublime Text 2 developer to add a PySys_SetArgvEx(argc, argv, updatepath) call after Py_Initialize().

Using Package Control
Install this sublime text 2/3 package via Package Control;
Search for package: "InputArgs"
or,
OSX:
$ cd ~/Library/Application\ Support/Sublime\ Text\ <2/3>/Packages/
$ git clone git://github.com/bilalba/InputArgs.git InputArgs
Linux (Ubuntu like distros):
$ cd ~/.config/sublime-text-<2/3>/Packages/
$ git clone git://github.com/bilalba/InputArgs.git InputArgs
Windows:
Copy the directory to:
"C:\Users\<username>\AppData\Roaming\Sublime Text <2/3>\Packages"