I am trying to run/debug my python project from IntelliJ Ultimate 2018.1. I have defined a python SDK, a Django local server (as the project uses Django as a template language), the PYTHONPATH is properly defined, etc. If I execute
python manage.py runserver
from my MacOS terminal, the server starts normally.
When I am trying to run my IntelliJ configuration, it fails, with message:
/usr/bin/python2.7 -d /Users/my_user/dev/github/my_project/manage.py runserver 8000
Traceback (most recent call last):
File "/Users/my_user/dev/github/my_project/manage.py", line 19, in <module>
paths = importlib.import_module('settings.' + server + '.paths')
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File "/Users/my_user/dev/github/my_project/settings/__init__.py", line 11, in <module>
paths = importlib.import_module('my_project.settings.' + server + '.paths')
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named my_project.settings.local.paths
The settings.local folder does contains the __init__.py file, and also settings folder and the root folder of my project.
Doing a few hours of research over the internet I have realised that the main problem is to include local modules on the classpath, so they are available for server startup. For PyCharm, this is clearly explained here, and I was able to run the server from PyCharm. However, when trying to do the same thing in IntelliJ, this never works. Some people write about it here for example, but that didn't worked out for me.
I have tried using a system interpreter and also a virtual environment, created with PyCharm, with no luck. I am using python 2.7, Django 1.11 and MacOS High Sierra. Is this even possible with IntelliJ? I wonder why would people buy PyCharm if the same things can be accomplished (and so much more) with IntelliJ. Also, I have noticed that when I change a setting in IntelliJ run profile (the Django local server profile), this change is reflected back in PyCharm and viceversa. This seems to me like a bug from JetBrains, as two distinct apps somehow share the same config, probably due to the fact that the same project is loaded in both apps.
The problem was in fact trivial, as clarified with JetBrains support: I needed to set the parent folder of my_project as content root (/Users/my_user/dev/github/), instead of using /Users/my_user/dev/github/my_project/ directly. This was needed because the source code contained imports from module my_project which could not be resolved, as there was no subfolder my_project inside of my main project folder. I implemented this change in Project settings -> Modules view, Project settings -> Facets view and also in the run configuration.
Related
I am trying to start learning python bottle framework, I've installed python 2.7.11, and installed pip too, I've installed bottle using
pip install bottle
Collecting bottle
Using cached bottle-0.12.9.tar.gz
Installing collected packages: bottle
Running setup.py install for bottle ... done
Successfully installed bottle-0.12.9
Now I tried to run the example code from bottle website
from bottle import route, run, template
#route('/hello/<name>')
def index(name):
return template('<b>Hello {{name}}</b>!', name=name)
run(host='localhost', port=8080)
when I run this code it throws the following error
Traceback (most recent call last):
File "C:/Users/SID/Desktop/bottle.py", line 1, in <module>
from bottle import route, run, template
File "C:/Users/SID/Desktop\bottle.py", line 1, in <module>
from bottle import route, run, template
ImportError: cannot import name route
I don't know what went wrong could some one guide me, Is it the error with the code? or in bottle installation?
Note: I Tried python 3.4.3 too still facing same error while running program and I'm using windows 8.1 in virtual box
You have bottle.py file within your project folder. Problem occurred because python module C:/Users/SID/Desktop/bottle.py shadowed bottle.py module which installed by pip. Rename file which shadow real bottle.py module to fix import problem.
Location of file which shall be renamed is C:/Users/SID/Desktop/bottle.py.
When a module named bottle is imported, the interpreter first searches for a built-in module with that name. If not found, as in this case it then searches for a file named bottle.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:
the directory containing the input script (or the current directory).
PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH).
the installation-dependent default.
Make sure bottle is in PYTHONPATH. More info on PYTHONPATH here
I have Eclipse Version: 4.2.1 and PyDev version 2.7.1 installed on my 64-bit Ubuntu.
I am using Python 2.7 and I have this problem with Eclipse that it doesn't recognize my un-imported methods. For example if I write a code like this:
def main():
myfiles = os.listdir('src')
if __name__ == '__main__':
main()
print'done!'
I get this error:
Traceback (most recent call last):
File "tset.py", line 5, in <module>
main()
File "tset.py", line 2, in main
myfiles = os.listdir('src')
NameError: global name 'os' is not defined
which is a pretty obvious error because I didn't write "import os" at the beginning of my code. My problem is that Eclipse doesn't highlight these errors for me anymore. Either I have to find them by myself or I will find out about them when I run my code.
My Eclipse was working fine before but I don't know what did I change that this happened.
I should also mention that I have "lib" folder in my project and in that folder I have a few of my own modules and I have added the "lib" folder to PYTHONPATH of my project. And the code that I am running is in another folder named "test" and that's not in the PYTHONPATH.
The problem was that my code was in a folder like this:
/MyProject/src/test/test.py
But the "src" folder was not in the PYTHONPATH. That is why Eclipse was not recognizing them as a source code and was not analyzing them.
To fix this go to:
Eclipse -> Project -> Properties -> PyDev-PYTHONPATH -> Source Folders
and add "/MyProject/src" to source folders. (I only had "/MyProject/src/lib" in my source folders)
In addition to the answer by #183.amir, if one of your apps is symlinked (not an actual directory), you need to add it to PYTHONPATH separately (with the steps described above).
Im running a solaris server which uses supervisor to monitor some Python applications.
Previously, I could run the command:
paster serve /opt/pyapps/menuadmin/prod.ini
from any directory on the server. There were some recent issues and the /opt folder was restored from a previous backup. This folder contained all of the applications including supervisor.
Now we are facing issues where supervisor will not start the applications because of "version conflicts" in Pylons.
This is where it gets weird and it makes no sense why these errors would occur.
If I run the paster command from outside of the program directory, it will throw the version conflict error. eg:
cd /
paster serve /opt/pyapps/menuadmin/prod.ini
Traceback (most recent call last):
File "/opt/csw/bin/paster", line 8, in <module>
load_entry_point('PasteScript==1.7.5', 'console_scripts', 'paster')()
File "/opt/csw/lib/python2.6/site-packages/PasteScript-1.7.5-py2.6.egg/paste/script/command.py", line 93, in run
commands = get_commands()
File "/opt/csw/lib/python2.6/site-packages/PasteScript-1.7.5-py2.6.egg/paste/script/command.py", line 135, in get_commands
plugins = pluginlib.resolve_plugins(plugins)
File "/opt/csw/lib/python2.6/site-packages/PasteScript-1.7.5-py2.6.egg/paste/script/pluginlib.py", line 82, in resolve_plugins
pkg_resources.require(plugin)
File "/opt/csw/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg/pkg_resources.py", line 626, in require
File "/opt/csw/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg/pkg_resources.py", line 528, in resolve
pkg_resources.VersionConflict: (Pylons 0.9.7 (/opt/csw/lib/python2.6/site-packages/Pylons-0.9.7-py2.6.egg), Requirement.parse('Pylons>=0.10'))
But if I run the command from inside the program directory, it will run fine. eg:
cd /opt/pyapps/menuadmin/
paster serve /opt/pyapps/menuadmin/prod.ini
Starting server in PID 29902.
serving on http://127.0.0.1:3002
I absolutely cannot get my head around why this would happen!
Any thoughts or comments at all are appreciated!!!!
Based upon what you have said it seems you are running two different version of paster. The first version is running the older Pylons package 0.9.7, whilst the second has the more up to date version that meets or exceeds your app's requirements.
What I would do is first check which version of paster you are running. From outside of the project just run:
which paster
Then run the same command again within the project directory and compare the results. I suspect that you will find that the paths differ. If that is the case then all you need to do is update the version of pylons for the first version, which I'm guessing is the global install.
However, as others have commented it would be better to run apps within virtualenv, especially if as you seem to indicate you have multiple virtualenv and thus multiple projects. Trust me when I say it will save you from loads of headaches later on, from someone that didn't do this originally.
Problem
When trying to run one of my custom Django management commands (send_notify_emails), I get the following error:
$ python web_apps/manage.py send_notify_emails
Traceback (most recent call last):
File "web_apps/manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 436, in execute_manager
setup_environ(settings_mod)
File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 419, in setup_environ
project_module = import_module(project_name)
File "/usr/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
ImportError: No module named my_django_app-1.0
Background
I have a Django site with two apps in it. The path to the site directory (which includes the app module directories, as well as settings.py, urls.py and manage.py) is /srv/web_apps. This is a symbolic link to /usr/share/my_django_app-1.0, which is an svn export of a production release tag. This way I can change my app version over by just moving the symbolic link to the path for the new production version, and easily change back to an earlier release if I need to.
My django.wsgi file adds /srv and /srv/web_apps to the Python path so that mod_wsgi can find my settings and url files, as well as the app modules.
The ONLY place that my_django_app-1.0 appears is the directory path, it is not anywhere in my settings.py or otherwise, so Django must be getting the module name from the path.
What seems to be happening is Django is resolving the package name for my app by following the symbolic link and using the name of the target folder, instead of the symbolic link itself. When I run manage.py, Django tries to import my_django_app-1.0 when it should be importing web_apps.
I have a Django site with two apps in it. The path to the site
directory (which includes the app module directories, as well as
settings.py, urls.py and manage.py) is /srv/web_apps. This is a
symbolic link to /usr/share/my_django_app-1.0, which is an svn export
of a production release tag. This way I can change my app version over
by just moving the symbolic link to the path for the new production
version, and easily change back to an earlier release if I need to.
What you're describing is basically the exact reason why people like virtualenv so much.
I'd suggest taking a read through of mod_wsgi Virtual Environments.
The issue is that __file__ is returning the symlink a relative path which depending
on where it's being imported from (inside a symlink'd path..), thats how it'll report
it's home. Since directories are the basic structure of modules, if you have a directory
with __init__.py in it, then whatever that directory is named will be the 'name'
if you import it.
You might be able to override this behavior, but that'd be the wrong way to go about
things - check out virtualenv, or setup separate directories per version and just use
underscores instead of periods. myApp_1_0_0, etc.
Consider the following scenario
mkdir real_directory
ln -s real_directory symlink_directory
cat >>real_directory/__init__.py <<EOF
import os
print
print '__name__ == %s' % (__name__)
print '__file__ == %s' % (__file__)
print ' abspath == %s' % os.path.abspath(__file__)
print 'realpath == %s' % os.path.realpath(os.path.abspath(__file__))
print
EOF
python -c "import real_directory"
__name__ == real_directory
__file__ == real_directory/__init__.py
abspath == /Users/nar/pt/real_directory/__init__.py
realpath == /Users/nar/pt/real_directory/__init__.py
python -c "import symlink_directory"
__name__ == symlink_directory
__file__ == symlink_directory/__init__.pyc
abspath == /Users/nar/pt/symlink_directory/__init__.pyc
realpath == /Users/nar/pt/real_directory/__init__.pyc
I have difficulty especially in installing MySQLdb module (MySQL-python-1.2.3c1), to connect to the MySQL in MAMP stack.
I've done a number of things such as copying the mysql include directory and library (including plugin) from a fresh installation of mysql (version 5.1.47) to the one inside MAMP (version 5.1.37).
Now, the MySQLdb module build and install doesnt give me error.
The error happens when I'm calling 'import MySQLdb' from python shell (version 2.6).
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Any idea, what else do I need to do to make it works?
Thanks a bunch,
Robert
=========
Add the system response after using virtualenv as suggested by Hank Gay below...
(MyDjangoProject)MyMacPro:MyDjangoProject rhenru$ which python
/Users/rhenru/Workspace/django/MyDjangoProject/bin/python
After I run python in virtualenv, importing MySQLdb:
>>> import MySQLdb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
import sys and sys.path
>>> import sys
>>> print sys.path
['', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python26.zip', '/Library/Python/2.6/site-packages/PyXML-0.8.4-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/pydot-1.0.2-py2.6.egg', '/Library/Python/2.6/site-packages/pyparsing-1.5.2-py2.6.egg', '/Library/Python/2.6/site-packages/vobject-0.8.1c-py2.6.egg', '/Library/Python/2.6/site-packages/pytz-2010h-py2.6.egg', '/Library/Python/2.6/site-packages/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/distribute-0.6.12-py2.6.egg', '/Library/Python/2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-darwin', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/Extras/lib/python', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-tk', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-old', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages', '/Library/Python/2.6/site-packages', '/Library/Python/2.6/site-packages/PIL', '/Library/Python/2.6/site-packages/setuptools-0.6c11-py2.6.egg-info', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode']
How are you installing MySQL-Python? I just tested in a fresh virtualenv and pip install mysql-python seems to have done the trick.
UPDATE:
pip is sort of like a package manager for Python packages.
By default, pip installs to your current site-packages directory, which is on your $PYTHONPATH. This lets other libraries/applications (like Django) access it. pip also works well with virtualenv (it should; Ian Bicking wrote them both), which is a nifty library that lets you sandbox an application. This is nice because it means you can try out new things without polluting (or even needing write access to) the global site-packages directory.
It probably seems like yak-shaving right now, but I'd say it's worth the effort to get up to speed on pip and virtualenv (you may also want to look into virtualenvwrapper, but we'll skip that for now; it's just sugar for virtualenv). It will lead to a slightly more complicated deployment scenario than putting everything in the global site-packages, but for development it's really no harder, and there are lots of good guides to deploying using a virtualenv.
I'd recommend something like the following:
curl -0 http://python-distribute.org/distribute_setup.py
python distribute_setup.py
easy_install pip
pip install virtualenv
virtualenv --distribute MyDjangoProject --no-site-packages
cd MyDjangoProject
source bin/activate (this activates the sandbox that virtualenv created)
pip install django mysql-python
At this point, you should have a totally functional Django+MySQL install (if I missed any steps, just comment and I'll try to add it in). You can start your Django project like this: django-admin.py startproject MyDjangoProject. cd into your project's directory, edit your settings.py file to point to your MySQL database, and run the dev server to test it out like so: ./manage.py runserver (you may need to chmod u+x your manage.py file). Voila! You should be able to access your site on localhost:8000. When you're done working on the project, you can just use deactivate to exit the virtualenv sandbox.
Try not to hold all this against Django: a lot of it is just best practices stuff for working with Python libraries. You could get by with a lot less, but this way it's more reproducible and you're less likely to accidentally mess up one of this project's dependencies when working on a different project.
I had this problem and it turned out to be due to an errant configuration:
export VERSIONER_PYTHON_PREFER_32_BIT=yes
I can't recall what I had this enabled for (some package that required 32-bit), probably related to Google AppEngine. But Setting it to 'no' solved by issues.
Otherwise I just installed everything using homebrew and pip.