OSX, Python 2.7, pip, virtualenv. Been using these for years with no issues.
I'm not sure what changed, but recently my environment completely broke for Django after working perfectly fine for a while. The same checkout runs fine on my friend's computer with a similar setup.
Things I've already tried: deleting my venv and creating a new one with fresh installs from requirements.txt, uninstalling logging outside the venv and reinstalling inside, reinstalling pip.
I get the same traceback for any manage.py command. It appears to be having issues with the logging module:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/core/management/__init__.py", line 453, in execute_from_command_line
utility.execute()
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/core/management/__init__.py", line 376, in execute
sys.stdout.write(self.main_help_text() + '\n')
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/core/management/__init__.py", line 242, in main_help_text
for name, app in six.iteritems(get_commands()):
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/core/management/__init__.py", line 109, in get_commands
apps = settings.INSTALLED_APPS
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/conf/__init__.py", line 52, in __getattr__
self._setup(name)
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/conf/__init__.py", line 48, in _setup
self._configure_logging()
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/conf/__init__.py", line 75, in _configure_logging
logging_config_func(DEFAULT_LOGGING)
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/utils/dictconfig.py", line 555, in dictConfig
dictConfigClass(config).configure()
File "/Users/rfong/Dropbox/code/lattis_workspace/lattis_repo/venv/lib/python2. 7/site-packages/django/utils/dictconfig.py", line 323, in configure
del logging._handlerList[:]
AttributeError: 'module' object has no attribute '_handlerList'
It seems that you installed outdated 0.4.9.6 version of logging module, presumably with pip. Correct version, shipped with python 2.7 is 0.5.1.2, and I suppose in your case might be located in /Library/Python/2.7/lib/logging. Correct version can be uploaded from python svn.
If you use pip, you always can find out which module versions are installed with
$ pip freeze
to ensure that correct versions of packages are installed, use following syntax:
$ pip install <package>==<version>
this will save you lot of pain and efforts, and almost a must on production environments.
Related
I'm attempting to briefcase a hello-world type script, from a virtual environment created using pipenv. My original python installation building using Anaconda, though I don't really need it as I don't use any of the scientific computing stack. I am not sure what I'm experiencing is a pipenv error, a pip error, or a briefcase error. If you could help me sort this, I would really appreciate it.
Briefcase
(root) C:\Users\stmwr\Dropbox\SoftwareProjects\helloworld-br\helloworld>python setup.py windows
running windows
Traceback (most recent call last):
File "setup.py", line 73, in <module>
'app_requires': [
File "C:\Users\stmwr\Anaconda3\lib\site-packages\setuptools\__init__.py", line 129, in setup
return distutils.core.setup(**attrs)
File "C:\Users\stmwr\Anaconda3\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Users\stmwr\Anaconda3\lib\distutils\dist.py", line 955, in run_commands
self.run_command(cmd)
File "C:\Users\stmwr\Anaconda3\lib\distutils\dist.py", line 973, in run_command
cmd_obj.ensure_finalized()
File "C:\Users\stmwr\Anaconda3\lib\distutils\cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "C:\Users\stmwr\Anaconda3\lib\site-packages\briefcase\windows.py", line 18, in finalize_options
finalized = self.get_finalized_command('app')
File "C:\Users\stmwr\Anaconda3\lib\distutils\cmd.py", line 299, in get_finalized_command
cmd_obj.ensure_finalized()
File "C:\Users\stmwr\Anaconda3\lib\distutils\cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "C:\Users\stmwr\Anaconda3\lib\site-packages\briefcase\app.py", line 123, in finalize_options
pip.utils.ensure_dir(self.download_dir)
AttributeError: module 'pip' has no attribute 'utils'
It's likely that this is an issue with Pipenv not supporting Pip 10 yet; in Pip 10, all internal APIs were moved around, which broke all applications that depended on them. I believe the aim is to have a release out soon.
If you can wait a couple of days and then update Pipenv, that will probably be easiest. If you can't wait, you could try to downgrade Pip to version 9.0.3, which should work again.
I am migrating a Django project to production and was going through python manage.py collectstatic phase.
After running this command, I get an error:
ImportError: No module named djangocms_admin_style
However, I clearly have this module installed as both pip list and a manual inspection of the directories shows.
What's more, preceeding this error, there is the following traceback:
File "manage.py", line 10, in
execute_from_command_line(sys.argv) File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 354, in execute_from_command_line
utility.execute() File "/usr/local/lib/python2.7/site-packages/django/core/management/init.py",
line 328, in execute
django.setup() File "/usr/local/lib/python2.7/site-packages/django/init.py", line 18,
in setup
apps.populate(settings.INSTALLED_APPS) File "/usr/local/lib/python2.7/site-packages/django/apps/registry.py", line
85, in populate
app_config = AppConfig.create(entry) File "/usr/local/lib/python2.7/site-packages/django/apps/config.py", line
86, in create
module = import_module(entry) File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
import_module
import(name)
What confuses me about the traceback is that there are multiple references to the system-wide Python instead of the one I created within the virtualenv. Why is that? I suspect that this has something to do with the error above.
If it helps, I do not have anything custom (including django_admin_styles) installed in the system Python environment, only within my virtualenv, which is also activated when the commands are run.
Any help is appreciated.
Are you using VSCode by any chance? Along with setting up the environment, you need to reference the correct python executable by setting the "python.pythonPath" setting to the path of the python executable inside your virtual environment.
I had a working mezzanine project configured with apache and mod_wsgi. I tried to added an app to the project and restarted apache and suddenly the project is throwing the error even after undoing the changes. Getting the same error when I'm trying to run python manage.py check:
Traceback (most recent call last):
File "manage.py", line 14, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 284, in execute
self.validate()
File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 310, in validate
num_errors = get_validation_errors(s, app)
File "/usr/lib/python2.7/dist-packages/django/core/management/validation.py", line 34, in get_validation_errors
for (app_name, error) in get_app_errors().items():
File "/usr/lib/python2.7/dist-packages/django/db/models/loading.py", line 196, in get_app_errors
self._populate()
File "/usr/lib/python2.7/dist-packages/django/db/models/loading.py", line 75, in _populate
self.load_app(app_name, True)
File "/usr/lib/python2.7/dist-packages/django/db/models/loading.py", line 97, in load_app
app_module = import_module(app_name)
File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, in import_module
__import__(name)
File "/usr/local/lib/python2.7/dist-packages/mezzanine/boot/__init__.py", line 16, in <module>
from django.apps import apps
ImportError: No module named apps
Path to django: "/usr/local/lib/python2.7/dist-packages/django", and it has folder named "apps" and "init.py" file exists inside the folder.
I then created a whole new mezzanine project and ran python manage.py check, and getting the same error. It means not any mezzanine project is working. I tried updating and reinstalling django and mezzanine but no use. On the other hand, a simple django project is running fine.
It seems there is some problem with mezzanine.
I went through the other related questions but couldn't get it resolved. Any help would be much appreciated. Thanks in advance.
You say you have a folder named apps in your Django installation, but the traceback shows it is executing code that was removed in 1.7, the same version that introduced django.apps. Your installation is most likely corrupt and has files from different versions.
Uninstall Django from your Python installation, and completely remove the /usr/local/lib/python2.7/dist-pacakges/django/ folder. Then, reinstall a Django version that is compatible with your version of Mezzanine.
It seems that you've installed Django into your global Python installation. This can easily cause such problems when multiple projects need to use different versions of python packages. It is recommended to use a virtual environment to manage requirements for your projects in an isolated environment and prevent such conflicts.
I finally resolved the ubiquitous MySQL-python/OSX (10.7 64-bit) debacle and have Python and MySQL working fine by using 32-bit MySQL and calling python with 'arch -i386'. Py scripts outside of Django are correctly querying MySQL etc. However, when I try to fire up Django and invoke the development server, I'm getting the error I was getting previously when using 64-bit Python:
django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_mysql.so, 2): no suitable image found. Did find:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_mysql.so: mach-o, but wrong architecture
In my .bash_profile I have
alias python='arch -i386 python2.7'
export VERSIONER_PYTHON_PREFER_64_BIT=no
export VERSIONER_PYTHON_PREFER_32_BIT=yes
So I don't understand how Django is invoking python and why it isn't honoring what I have in .bash_profile. What do I need to change in Django to get it to invoke 32-bit Python? The full traceback when I do 'python manage.py runserver' is:
Traceback (most recent call last):
File "manage.py", line 14, in <module>
execute_manager(settings)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 209, in execute
translation.activate('en-us')
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/translation/__init__.py", line 100, in activate
return _trans.activate(language)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 202, in activate
_active.value = translation(language)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 185, in translation
default_translation = _fetch(settings.LANGUAGE_CODE)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 162, in _fetch
app = import_module(appname)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/admin/__init__.py", line 3, in <module>
from django.contrib.admin.helpers import ACTION_CHECKBOX_NAME
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/admin/helpers.py", line 3, in <module>
from django.contrib.admin.util import (flatten_fieldsets, lookup_field,
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/admin/util.py", line 1, in <module>
from django.db import models
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/__init__.py", line 78, in <module>
connection = connections[DEFAULT_DB_ALIAS]
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/utils.py", line 93, in __getitem__
backend = load_backend(db['ENGINE'])
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/utils.py", line 33, in load_backend
return import_module('.base', backend_name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 14, in <module>
raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_mysql.so, 2): no suitable image found. Did find:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_mysql.so: mach-o, but wrong architecture
The VERSIONER_PYTHON_PREFER_32_BIT environment variable is an Apple-supplied feature. It only applies to the Apple-supplied system Pythons in Mac OS X 10.6 and 10.7. From the path shown, you are using a non-system Python (installed in /Library/Frameworks, possibly from a python.org installer). VERSIONER_PYTHON_PREFER_32_BIT will have no affect on it. Have you tried launching the development server with something like:
arch -i386 /usr/local/bin/python2.7 django-admin.py ...
You still may run into trouble if Django launches Python interpreters in subprocesses which will default to 64-bit. You should either get everything working in 64-bit mode or stick to a complete 32-bit chain of Python and MySQLdb. You could save yourself a lot of trouble by installing a complete solution from a third-party distributor like MacPorts or Homebrew.
I had a similar issue with Snow Leopard, but was using a virtual environment for all my work. If you're using one too (which is the recommended way to work with Django), then you can force the version of python your virtual environment uses. When you create a new virtual environment, just say something like:
virtualenv --python=/Library/Frameworks/Python.framework/Versions/2.7/bin/python new-environment
I am trying to install distribute using ActivePython 3.1.2 on Windows.
Running python distribute_setup.py as described on the cheese shop give me:
No setuptools distribution found
running install
Traceback (most recent call last):
File "setup.py", line 177, in
scripts = scripts,
File "C:\Dev\Python_x86\3.1\lib\distutils\core.py", line 149, in setup
dist.run_commands()
File "C:\Dev\Python_x86\3.1\lib\distutils\dist.py", line 919, in run_commands
self.run_command(cmd)
File "C:\Dev\Python_x86\3.1\lib\distutils\dist.py", line 938, in run_command
cmd_obj.run()
File "build\src\setuptools\command\install.py", line 73, in run
self.do_egg_install()
File "build\src\setuptools\command\install.py", line 82, in do_egg_install
easy_install = self.distribution.get_command_class('easy_install')
File "build\src\setuptools\dist.py", line 361, in get_command_class
self.cmdclass[command] = cmdclass = ep.load()
File "build\src\pkg_resources.py", line 1953, in load
entry = import(self.module_name, globals(),globals(), ['name'])
File "build\src\setuptools\command\easy_install.py", line 16, in
from setuptools.sandbox import run_setup
File "build\src\setuptools\sandbox.py", line 164, in
fromlist=['name']).file)
AttributeError: 'module' object has no attribute 'file'
Something went wrong during the installation.
See the error message above.
Is there possibly an unknown dependency that I'm missing?
Downloading the source tarball and executing python setup.py install produces the exact same output.
Edit: Added the full stack trace for running the installer.
So apparently the python.org version of Python3 is different from the ActiveState version of Python3. (You should file a bug to someone (I'm not sure to whom))
The fix I have (I'm not sure of all the repercussions)
Download:
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.12.tar.gz#md5=5a52e961f8d8799d243fe8220f9d760e
and then extracting it and modify:
distribute-0.6.12\setuptools\sandbox.py:165
from:
except ImportError:
to
except (ImportError, AttributeError):
that will silence the error and allow you to run:
python setup.py install
It took me awhile to find a package from http://pypi.python.org/pypi?:action=browse&c=533&show=all that would actually install on either version of Python3. "files" was the first package, and since it installed I am pretty sure that easy_install is working for both copies of Python3.
...hope it works! (That's all I can help you with)
this is a bug with Distribute http://bitbucket.org/tarek/distribute/issue/151 ... it should be fixed by next release (0.6.13). It is only reproducible with PyWin32 installed; and ActivePython comes bundled with PyWin32.