I try django-admin.py makemessages -l zh_CN but has error :
CommandError: Can't find msguniq. Make sure you have GNU gettext tools 0.15 or newer installed.
after I use brew install gettext,it still get wrong.
Do I need to do something? here is my terminal screenshot
Please guide me thank you.
In Ubuntu:
$ sudo apt-get install gettext
For Mac users, after installing Homebrew and gettext as #Louis Barranqueiro says (steps 1 and 2):
Install Homebrew : /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Install GNU gettext : brew install gettext
You shouldn't use brew link gettext --force in step 3, because it is risky (as Brew advises if you try). A better workaround is to set a new PATH variable for your virtual environment. So, in the postactivate file, which is located in the bin folder of your virtual environment folder, type:
export TEMP_PATH=$PATH
export PATH=$PATH:/usr/local/Cellar/gettext/0.19.7/bin
Note that you have to replace 0.19.7 by the version that is installed in your machine.
And in your predeactivate file, which is located in the same folder of postactivate file, type:
export PATH=$TEMP_PATH
unset TEMP_PATH
Now you can use the python manage.py makemessages -l <desired_language> without worries. :)
Cheers.
This procedure worked for me (OSX 10.11.2 - python v3.5 and Django 1.8)
It should work with your configuration.
Install gettext GNU tools with Homebrew using Terminal
Install Homebrew : /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Install GNU gettext : brew install gettext
Create symlink : brew link gettext --force
This solution worked for me ( win. 7, 8 and 10 )
You need to download two folders:
gettext-runtime_0.18.1.1-2_win32
gettext-tools-dev_0.18.1.1-2_win32
You can find them here.
After you download them, unzip them and add the directory of the bin file of the both folders to the system variables PATH of your pc.
You will also need a file named libstdc++-6.dll download it from here and place it in your system directory. You will find adequate details on system directory here.
And that’s it. Hope it is useful for you.
Just below solution solved my problem. I am using Windows 10 64bit
1- Go to this link :
https://mlocati.github.io/articles/gettext-iconv-windows.html
2- Download 32 or 64 bit shared and static windows installation files
3-Install both of files
4-Restart your computer
Hi first of all make sure that your virtual environment is not in your root folder. I think it's better practice to keep your virtual environment outside of the root folder. Obviously make sure your environment is activated. Of course make sure you have gettext installed as well.
If your env folder is in your root folder
To test this just make sure you add {% load i18n %} in all your templates, choose a template and do something like this:
<h1>{% trans 'My Test to be translated' %}</h1>
Now run this command
django-admin makemessages -l 'zh_CN' -i your_venv
(Make sure you replace your_venv to the name of your virtual environment.
After you run the above command, you should get this in your terminal.
processing locale zh_CN
Now you should have a locale folder like this: locale/cn/LC_MESSAGES/django.po
Now you will need to compile the messages. Run this command
django-admin compilemessages
In your locale folder, now you should get you should see django.mo file as well, but you will notice the difference in django.po file. Just add your translation there, and you can test again by setting your en language to LANGUAGE_CODE = 'zh_CN' then just refresh and test the h1 string will be translated to Chinese.
In order for the above to work in your settings.py ensure you have this here, for now most important is the LOCALE_PATHS, but please check if this ('zh_CN', _('Chinese')), is correct
LANGUAGES = [
('zh_CN', _('Chinese')),
('en', _('English')),
]
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True
LOCALE_PATHS = [
os.path.join(BASE_DIR, 'locale'),
]
In this reply, the most important part is to realize where your virtual environment is located. Reason why you get all these errors.
Please make sure you refer to this video here, it's a great tutorial.
https://www.youtube.com/watch?v=xI97sLMd1rM
#max-malysh's answer solved it for me —without touching system files.
Copy and run each of the following:
brew install gettext
GETTEXT_PATH="/usr/local/Cellar/gettext/0.19.8.1/bin"
FILE="venv/bin/activate"
echo "" >> $FILE
echo "export PATH=\$PATH:$GETTEXT_PATH" >> $FILE
source venv/bin/activate
GETTEXT_PATH="/usr/local/Cellar/gettext/0.19.8.1/bin" stores gettext_path in a shell variable —adapt the version number according to what brew install gettext
FILE="venv/bin/activate" stores the path to the venv shell script
echo "" >> $FILE adds an empty line at the end of the to make sure the next command is on its own line
echo "export PATH=\$PATH:$GETTEXT_PATH" >> $FILE adds a command to the venv shell script; this command adds the path to gettext binaries to the global $PATH variable, so that they are used before OS binaries.
source venv/bin/activate runs the venv shell script so that variables are properly set. You can run this command more than once.
If you're using Docker just simply run below command:
apt-get update
Then:
apt-get install gettext
If you use fish shell, another way around is to add this path to $fish_user_paths.This variable is prepended to $PATH, so you don't have to set it in all your projects.
You can do it with the following command line :
set -U fish_user_paths /usr/local/Cellar/gettext/0.19.8.1/bin $fish_user_paths
Remember to replace 0.19.8.1 with your gettext version.
This sets $fish_user_paths as a Universal Variable. Here's what help says about Universal Variables :
A universal variable is a variable whose value is shared across all
instances of fish, now and in the future – even after a reboot. You
can make a variable universal with set -U
So setting this variable in your shell once (no need to do it in a config file) will save it even after logging out or rebooting.
that works for windows users.
i am using django 2
access this https://mlocati.github.io/articles/gettext-iconv-windows.html
2 download the static version for your system
after downloaded execute the setup.
restart your pc and it will work.
That is all. THANKS.!!!!
the problem is hinted in the output from brew...
it has installed the GNU gettext but hasn't linked it into your bin directory because OSX already provides a different version of gettext...
so Django doesn't know to run the version you installed from brew.
apparently brew is too cautious here though and you should just link it https://stackoverflow.com/a/9787791/202168
Related
I have latest GVim (v8.2) 64-bit and Miniconda Python 3.8.5 64-bit installed on Windows 10. I am working in the virtual environment da38 and included the following two lines in my $HOME\_vimrc file to point to the correct python interpreter and libraries for this environment:
set pythonthreehome=$HOME\miniconda3\envs\da38
set pythonthreedll=$HOME\miniconda3\envs\da38\python38.dll
Both :echo has('python3') and :echo has('python3_dynamic') return 1. I have installed Vim plugin dense-analysis/ale for python linting, and installed flake8 and black packages in da38 using conda install flake8 black. And I added the following lines in $HOME\_vimrc to configure this plugin:
let g:ale_linters = {'python': ['flake8']}
let g:ale_fixers = {'*': [], 'python': ['black']}
let g:ale_fix_on_save = 1
But the plugin does not show any error on a python file that has many by design: running flake8 test.py on command prompt returns a lot of errors. :ALEInfo repeats these two lines several times:
(executable check - failure) flake8
(finished - exit code 1) 'cmd /s/c "cd /d "C:\Users\Admin\Desktop" && black - < C:\Users\Admin\AppData\Local\Temp\VIBA694.tmp\test.py"'
I am wondering if somehow the correct python path is not being passed to Vim, but cannot figure out what else to do. Any help is much appreciated.
Thanks
UPDATE:
I think I narrowed down the problem. Linter plugin fails when I open test.py with vim from the desktop icon, but works if I first activate the virtual environment with conda activate da38 and then start vim on command prompt. I guess the desktop vim does not see the virtual environment, where the two packages flake8 and black are installed. So I believe the problem is how to add the appropriate python environment to the desktop vim. I should add the vim-conda plugin did not help.
UPDATE #2:
I managed to get vim-conda plugin working with gvim, and now the linter plugin works as expected.
UPDATE #3:
One can avoid using a plugin and instead hard-code the environment path in _vimrc (for windows):
let venv = 'da38'
let mypath = 'C:\Users\Admin\miniconda3\envs\' . venv . ';'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Scripts;'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Library\bin;'
let $PATH = mypath . $PATH
This code sticks the env path in front of default $PATH.
I have installed virtualenv and the virtualwrapper via apt-get, I got to a point where I created a virtual enviroment but however later on during that same day when I used the workon command it was not found. I further on went and inspected my home directory and .virtualenvs dir and the virtualenv I created earlier were still there.
Solving this problem took two steps:
Add this to your .bashrc / .bash_profile / .zshrc:
# load virtualenvwrapper for python (after custom PATHs)
venvwrap="virtualenvwrapper.sh"
/usr/bin/which -s $venvwrap
if [ $? -eq 0 ]; then
venvwrap=`/usr/bin/which $venvwrap`
source $venvwrap
fi
Then use:
source .bash_profile
# or .bashrc / .zshrc
to reflect the changes.
Additionally, if the terminal still sometimes cant find workon, use source .bash_profile to reset and find it again.
type source .profile in home directory from terminal.
Read the readme in the top of which virtualenvwrapper.sh
You need to source it inside bashrc
open ~/.profile
cd ~
nano .profile
add at the end
#virtualenvwrapper setup
export WORKON_HOME=$HOME/envs
export PROJECT_HOME=$HOME/dev
source /usr/local/bin/virtualenvwrapper.sh
to load your .profile file you just edited:
$ . .profile
I ran in to this problem too and I simply needed to logout and log back in.
This read in the changes which the debian package manager made to my system at /etc/bash_completion.d/virtualenvwrapper
I've been usually installed python packages through pip.
For Google App Engine, I need to install packages to another target directory.
I've tried:
pip install -I flask-restful --target ./lib
but it fails with:
must supply either home or prefix/exec-prefix -- not both
How can I get this to work?
Are you using OS X and Homebrew? The Homebrew python page https://github.com/Homebrew/brew/blob/master/docs/Homebrew-and-Python.md calls out a known issue with pip and a work around.
Worked for me.
You can make this "empty prefix" the default by adding a
~/.pydistutils.cfg file with the following contents:
[install]
prefix=
Edit: The Homebrew page was later changed to recommend passing --prefix on the command line, as discussed in the comments below. Here is the last version which contained that text. Unfortunately this only works for sdists, not wheels.
The issue was reported to pip, which later fixed it for --user. That's probably why the section has now been removed from the Homebrew page. However, the problem still occurs when using --target as in the question above.
I believe there is a simpler solution to this problem (Homebrew's Python on macOS) that won't break your normal pip operations.
All you have to do is to create a setup.cfg file at the root directory of your project, usually where your main __init__.py or executable py file is. So if the root folder of your project is: /path/to/my/project/, create a setup.cfg file in there and put the magic words inside:
[install]
prefix=
OK, now you sould be able to run pip's commands for that folder:
pip install package -t /path/to/my/project/
This command will run gracefully for that folder only. Just copy setup.cfg to whatever other projects you might have. No need to write a .pydistutils.cfg on your home directory.
After you are done installing the modules, you may remove setup.cfg.
On OSX(mac), assuming a project folder called /var/myproject
cd /var/myproject
Create a file called setup.cfg and add
[install]
prefix=
Run pip install <packagename> -t .
Another solution* for Homebrew users is simply to use a virtualenv.
Of course, that may remove the need for the target directory anyway - but even if it doesn't, I've found --target works by default (as in, without creating/modifying a config file) when in a virtual environment.
*I say solution; perhaps it's just another motivation to meticulously use venvs...
I hit errors with the other recommendations around --install-option="--prefix=lib". The only thing I found that worked is using PYTHONUSERBASE as described here.
export PYTHONUSERBASE=lib
pip install -I flask-restful --user
this is not exactly the same as --target, but it does the trick for me in any case.
As other mentioned, this is known bug with pip & python installed with homebrew.
If you create ~/.pydistutils.cfg file with "empty prefix" instruction it will fix this problem but it will break normal pip operations.
Until this bug is officially addressed, one of the options would be to create your own bash script that would handle this case:
#!/bin/bash
name=''
target=''
while getopts 'n:t:' flag; do
case "${flag}" in
n) name="${OPTARG}" ;;
t) target="${OPTARG}" ;;
esac
done
if [ -z "$target" ];
then
echo "Target parameter must be provided"
exit 1
fi
if [ -z "$name" ];
then
echo "Name parameter must be provided"
exit 1
fi
# current workaround for homebrew bug
file=$HOME'/.pydistutils.cfg'
touch $file
/bin/cat <<EOM >$file
[install]
prefix=
EOM
# end of current workaround for homebrew bug
pip install -I $name --target $target
# current workaround for homebrew bug
rm -rf $file
# end of current workaround for homebrew bug
This script wraps your command and:
accepts name and target parameters
checks if those parameters are empty
creates ~/.pydistutils.cfg file with "empty prefix" instruction in it
executes your pip command with provided parameters
removes ~/.pydistutils.cfg file
This script can be changed and adapted to address your needs but you get idea. And it allows you to run your command without braking pip. Hope it helps :)
If you're using virtualenv*, it might be a good idea to double check which pip you're using.
If you see something like /usr/local/bin/pip you've broken out of your environment. Reactivating your virtualenv will fix this:
VirtualEnv: $ source bin/activate
VirtualFish: $ vf activate [environ]
*: I use virtualfish, but I assume this tip is relevant to both.
I have a similar issue.
I use the --system flag to avoid the error as I decribe here on other thread where I explain the specific case of my situation.
I post this here expecting that can help anyone facing the same problem.
I have just installed python 2.7 using macports as:
sudo port install py27-numpy py27-scipy py27-matplotlib py27-ipython +notebook py27-pandas py27-sympy py27-nose
during the process it found some issues, mainly broken files related with py25-haslib that I managed to fix. Now it seems eveything is ok. I tested a few programs and they run as expected. Currently, I have two versions of python: 2.5 (Default, from when I worked in my former institution) and 2.7 (just installed):
which python
/usr/stsci/pyssg/Python-2.5.1/bin/python
which python2.7
/opt/local/bin/python2.7
The next move would be set the new python version 2.7 as default:
sudo port select --set python python27
sudo port select --set ipython ipython27
My question is: is there a way to go back to 2.5 in case something goes wrong?
I know a priori, nothing has to go wrong. But I have a few data reduction and analysis routines that work perfectly with the 2.5 version and I want to make sure I don´t mess up before setting the default.
if you want to revert, you can modify your .bash_profile or other login shell initialization to fix $PATH to not add "/Library/Frameworks/Python.framework/Versions/2.5/bin" to $PATH and/or to not have /usr/local/bin appear before /usr/bin on $PATH.
If you want to permanently remove the python.org installed version,
paste the following lines up to and including the chmod into a posix-
compatible shell:
tmpfile=/tmp/generate_file_list
cat <<"NOEXPAND" > "${tmpfile}"
#!/bin/sh
version="${1:-"2.5"}"
file -h /usr/local/bin/* | grep \
"symbolic link to ../../../Library/Frameworks/Python.framework/"\
"Versions/${version}" | cut -d : -f 1
echo "/Library/Frameworks/Python.framework/Versions/${version}"
echo "/Applications/Python ${version}"
set -- Applications Documentation Framework ProfileChanges \
SystemFixes UnixTools
for package do
echo "/Library/Receipts/Python${package}-${version}.pkg"
done
NOEXPAND
chmod ug+x ${tmpfile}
...excripted from troubleshooting question on python website
I am installing Python 2.7 on CentOS 5. I built and installed Python as follows
./configure --enable-shared --prefix=/usr/local
make
make install
When I try to run /usr/local/bin/python, I get this error message
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
When I run ldd on /usr/local/bin/python, I get
ldd /usr/local/bin/python
libpython2.7.so.1.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)
How do I tell Python where to find libpython?
Try the following:
LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python
Replace /usr/local/lib with the folder where you have installed libpython2.7.so.1.0 if it is not in /usr/local/lib.
If this works and you want to make the changes permanent, you have two options:
Add export LD_LIBRARY_PATH=/usr/local/lib to your .profile in your home directory (this works only if you are using a shell which loads this file when a new shell instance is started). This setting will affect your user only.
Add /usr/local/lib to /etc/ld.so.conf and run ldconfig. This is a system-wide setting of course.
Putting on my gravedigger hat...
The best way I've found to address this is at compile time. Since you're the one setting prefix anyway might as well tell the executable explicitly where to find its shared libraries. Unlike OpenSSL and other software packages, Python doesn't give you nice configure directives to handle alternate library paths (not everyone is root you know...) In the simplest case all you need is the following:
./configure --enable-shared \
--prefix=/usr/local \
LDFLAGS="-Wl,--rpath=/usr/local/lib"
Or if you prefer the non-linux version:
./configure --enable-shared \
--prefix=/usr/local \
LDFLAGS="-R/usr/local/lib"
The "rpath" flag tells python it has runtime libraries it needs in that particular path. You can take this idea further to handle dependencies installed to a different location than the standard system locations. For example, on my systems since I don't have root access and need to make almost completely self-contained Python installs, my configure line looks like this:
./configure --enable-shared \
--with-system-ffi \
--with-system-expat \
--enable-unicode=ucs4 \
--prefix=/apps/python-${PYTHON_VERSION} \
LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"
In this case I am compiling the libraries that python uses (like ffi, readline, etc) into an extlib directory within the python directory tree itself. This way I can tar the python-${PYTHON_VERSION} directory and land it anywhere and it will "work" (provided you don't run into libc or libm conflicts). This also helps when trying to run multiple versions of Python on the same box, as you don't need to keep changing your LD_LIBRARY_PATH or worry about picking up the wrong version of the Python library.
Edit: Forgot to mention, the compile will complain if you don't set the PYTHONPATH environment variable to what you use as your prefix and fail to compile some modules, e.g., to extend the above example, set the PYTHONPATH to the prefix used in the above example with export PYTHONPATH=/apps/python-${PYTHON_VERSION}...
I had the same problem and I solved it this way:
If you know where libpython resides at, I supposed it would be /usr/local/lib/libpython2.7.so.1.0 in your case, you can just create a symbolic link to it:
sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0
Then try running ldd again and see if it worked.
I installed Python 3.5 by Software Collections on CentOS 7 minimal. It all worked fine on its own, but I saw the shared library error mentioned in this question when I tried running a simple CGI script:
tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
I wanted a systemwide permanent solution that works for all users, so that excluded adding export statements to .profile or .bashrc files. There is a one-line solution, based on the Red Hat solutions page. Thanks for the comment that points it out:
echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh
After a restart, it's all good on the shell, but sometimes my web server still complains. There's another approach that always worked for both the shell and the server, and is more generic. I saw the solution here and then realized it's actually mentioned in one of the answers here as well! Anyway, on CentOS 7, these are the steps:
vim /etc/ld.so.conf
Which on my machine just had:
include ld.so.conf.d/*.conf
So I created a new file:
vim /etc/ld.so.conf.d/rh-python35.conf
And added:
/opt/rh/rh-python35/root/usr/lib64/
And to manually rebuild the cache:
sudo ldconfig
That's it, scripts work fine!
This was a temporary solution, which didn't work across reboots:
sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v
The -v (verbose) option was just to see what was going on. I saw that it did:
/opt/rh/rh-python35/root/usr/lib64:
libpython3.so.rh-python35 -> libpython3.so.rh-python35
libpython3.5m.so.rh-python35-1.0 -> libpython3.5m.so.rh-python35-1.0
This particular error went away. Incidentally, I had to chown the user to apache to get rid of a permission error after that.
Note that I used find to locate the directory for the library. You could also do:
sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0
Which on my VM returns:
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Which is the path I need to give to ldconfig, as shown above.
This worked for me...
$ sudo apt-get install python2.7-dev
On Solaris 11
Use LD_LIBRARY_PATH_64 to resolve symlink to python libs.
In my case for python3.6 LD_LIBRARY_PATH didn't work but LD_LIBRARY_PATH_64 did.
Hope this helps.
Regards
This answer would be helpful to those who have limited auth access on the server.
I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for resolution:
Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.
Verify that it's enabled by executing python3.5 --version. This should give you your python version.
Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path get the version again (just to verify that this path is working for you.)
Awesome, now please exit out of current shell by scl.
Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.
It won't give you the version but an error. In my case, it was
/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.
Use the following command to find where that file is located:
find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"
Above command would print the complete path (second line) of the file once located. In my case, output was
find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Here is the complete command for the python3.5 to work in such shared hosting which would give the version,
LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version
Finally, for shorthand, append the following alias in your ~/.bashrc
alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'
For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.
Well, there you go, now whenever you login again, you have got python351 to welcome you.
This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.
I installed using the command:
./configure --prefix=/usr \
--enable-shared \
--with-system-expat \
--with-system-ffi \
--enable-unicode=ucs4 &&
make
Now, as the root user:
make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0
Then I tried to execute python and got the error:
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Then, I logged out from root user and again tried to execute the Python and it worked successfully.
All it needs is the installation of libpython [3 or 2] dev files installation.
just install python-lib. (python27-lib). It will install libpython2.7.so1.0. We don't require to manually set anything.