#18249 closed Uncategorized (duplicate)
strange error with django-admin.py startproject myproject. Run with /bin/zsh
Reported by: | Owned by: | Lucas Simon | |
---|---|---|---|
Component: | Testing framework | Version: | 1.4 |
Severity: | Normal | Keywords: | django-admin.py, django, ksh, bash |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi,
Today I was testing a install application django with virtualenv, pip. I run Ubuntu Os 12.04, with /bin/zsk and https://github.com/robbyrussell/oh-my-zsh.
Look my steps:
$ virtualenv --distribute project New python executable in project4/bin/python Installing distribute.............................................................................................................................................................................................done. Installing pip...............done. $ cd project/ $ source bin/activate $ sudo pip install yolk Downloading/unpacking yolk Downloading yolk-0.4.3.tar.gz (86Kb): 86Kb downloaded Running setup.py egg_info for package yolk warning: no files found matching '*.txt' under directory 'tests' warning: no files found matching '*.conf' under directory 'docs' warning: no files found matching '*.css_t' under directory 'docs' warning: no files found matching 'indexsidebar.html' under directory 'docs' warning: no files found matching 'tests/test_cli.py' Requirement already satisfied (use --upgrade to upgrade): distribute in ./lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg (from yolk) Installing collected packages: yolk Running setup.py install for yolk warning: no files found matching '*.txt' under directory 'tests' warning: no files found matching '*.conf' under directory 'docs' warning: no files found matching '*.css_t' under directory 'docs' warning: no files found matching 'indexsidebar.html' under directory 'docs' warning: no files found matching 'tests/test_cli.py' Installing yolk script to /home/lucas/workspace-django/project4/bin Successfully installed yolk Cleaning up... $ sudo pip install Django Downloading/unpacking Django Downloading Django-1.4.tar.gz (7.6Mb): 7.6Mb downloaded Running setup.py egg_info for package Django Installing collected packages: Django Running setup.py install for Django changing mode of build/scripts-2.7/django-admin.py from 644 to 755 changing mode of /home/lucas/workspace-django/project4/bin/django-admin.py to 755 Successfully installed Django Cleaning up...
Here shows the problem
$ django-admin.py startproject myproject $ cd myproject/ (project)➜ myproject ls __init__.py manage.py settings.py urls.py (project)➜ myproject tree . ├── __init__.py ├── manage.py ├── settings.py └── urls.py $ yolk -l Django - 1.4 - active Python - 2.7.3 - active development (/usr/lib/python2.7/lib-dynload) argparse - 1.2.1 - active development (/usr/lib/python2.7) distribute - 0.6.24 - active pip - 1.1 - active wsgiref - 0.1.2 - active development (/usr/lib/python2.7) yolk - 0.4.3 - active $ cat manage.py #!/usr/bin/env python from django.core.management import execute_manager import imp try: imp.find_module('settings') # Assumed to be in the same directory. except ImportError: import sys sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n" % __file__) sys.exit(1) import settings if __name__ == "__main__": execute_manager(settings)
the file manage.py does not appear like a official manage.py in version django[1] 1.4.
And the structure of the folder myproject its strange. ==
Official: manage.py myapp/ __init__.py models.py mysite/ __init__.py settings.py urls.py My test app: (project)➜ myproject tree . ├── __init__.py ├── manage.py ├── settings.py └── urls.py
Totally different.
There are other thing that I did test. If I run this steps:
$ /bin/bash // Suppose I was in the folder myproject $ source ../bin/activate $ cd .. $ ls bin include lib local myproject $ django-admin.py startproject myproject2 $ cd myproject2 $ ls manage.py myproject2 $ tree . ├── manage.py └── myproject2 ├── __init__.py ├── settings.py ├── urls.py └── wsgi.py 1 directory, 5 files
OOOOOOOOOHHHHH JESUS !!!! It's Work!!
I can't understand this error or bug but I need to share to devel departament django
Change History (4)
follow-up: 2 comment:1 by , 13 years ago
follow-up: 4 comment:2 by , 13 years ago
Type: | Bug → Uncategorized |
---|
Replying to Alir3z4:
This happening to me, when i using virtualenv to create vm, on my system virtualenv is making a frsh python3 environment, So i using virtualenv2 instead, that will create fresh python2 env ;)
And no it's not a bug!
Can you tell-me how do you solved this?
comment:3 by , 13 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
It is most surely you have a previous global installation of Django already and things are mixing up. You need to manually cleanup any older Django version you had installed.
We are trying to figure out how to get the Django installation process/procedure to do/document that in #18115. I'm closing this ticket as duplicate.
Related to this: Why are you running your pip install Packages
with sudo? I suspect with that you are installing Django to the global level.
Precisely the point of using virtualenv (i.e. creating a virtual environment and activating it) is to be able to install these packages locally (inside the virtualenv) and as a normal user.
comment:4 by , 12 years ago
Replying to lucassrod@…:
Replying to Alir3z4:
This happening to me, when i using virtualenv to create vm, on my system virtualenv is making a frsh python3 environment, So i using virtualenv2 instead, that will create fresh python2 env ;)
And no it's not a bug!
Can you tell-me how do you solved this?
I told that already, i was using virtual-venv which at my Operation system is working with python3, So after a while i found out there is also a virtual-venv2 that working with python2 which is compatible with python2.
This happening to me, when i using virtualenv to create vm, on my system virtualenv is making a frsh python3 environment, So i using virtualenv2 instead, that will create fresh python2 env ;)
And no it's not a bug!