django-admin.py startproject creating duplicate settings.py files

[Yo-Yo Ma]

I have trunk installed from last night, and this is actual terminal
output (except for the stuff omitted on the left of the $):

(my_venv) myusername$ django-admin.py startproject foobarz
(my_venv) myusername$ ls foobarz/
__init__.py foobarz manage.py settings.py urls.py
(my_venv) myusername$ ls foobarz/foobarz/
__init__.py settings.py urls.py wsgi.py


I opened both settings.py files, and they are indeed identical files.
Is this intentional? I was interested in the new manage.py format, so
I thought I'd adjust my app to use it and whatever other new layout
features, but clearly this isn't correct.

[Carl Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nope, it's not correct, and I can't reproduce it either. I get just a
"manage.py" in the outer directory, and settings/urls/wsgi in the
package. My guess is that you already had an old-style startproject in
that "foobarz" directory or something. Try it again, and make sure the
target directory doesn't exist. Also try cleaning your Django repo of
untracked files; it's possible you somehow got extra files in the
conf/project_template directory that don't belong there?

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9DFf4ACgkQ8W4rlRKtE2cY7QCgvT5GMOuWLAgjl6QI3R/cBd6P
Py8AoIQaqmi11fOfx67mz+kzl8bi95iv
=zEND
-----END PGP SIGNATURE-----

[Yo-Yo Ma]

Hey Carl,

Thanks for the reply. I removed everything from my venv's site-
packages directory (except PIL and some other graph library), then
checked to make sure I wasn't able to use django-admin.py or my app's
manage.py scripts (ie, making sure there wasn't a global Django
install). I then reinstalled Django after pulling the latest master
from the github mirror, moved to ~/dev and then: (actual copy/paste
from my shell, minus find/replace of my personal/info):

(myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject
(myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a
. ..
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django-
admin.py startproject testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/
__init__.py manage.py settings.py testing123 urls.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/testing123/
__init__.py settings.py urls.py wsgi.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$

I'm not pulling your chain. I've never had this happen before, and
Django functions just fine otherwise (except for now issuing a warning
about using naive datetimes in Field.__init__, which is ironically
right up the alley of my other thread)

Note: In site-packages for the venv, I show Django-1.4b1-py2.7.egg-
info

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

[Carl Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/20/2012 09:19 PM, Yo-Yo Ma wrote:
> (myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject
> (myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a
> . ..
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django-
> admin.py startproject testing123
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123/
> __init__.py manage.py settings.py testing123 urls.py
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123/testing123/
> __init__.py settings.py urls.py wsgi.py
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$

Sorry, no idea. You could stick some "pdb.set_trace()" into the copy
function and see where it's getting those files from, I guess.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9DKFYACgkQ8W4rlRKtE2ciuwCg6ofAId96AwlvEkZunujznLiA
eGsAnjWKVXRR4pwPzWRBMPx6M7n3/V1V
=04ia
-----END PGP SIGNATURE-----

[Aymeric Augustin]

I discussed a similar problem on IRC a few days ago, which turned out to be caused by an incorrect installation of Django. The developer installed Django by cloning the git mirror and running "setup.py install". This doesn't remove obsolete files in the target install location.

See https://docs.djangoproject.com/en/dev/topics/install/#installing-the-development-version

If that doesn't explain your problem, you could search your entire system for directories called "project_template"; one of them probably contains the broken layout you're seeing, and that's the "active" installation of Django.

Installation issues are difficult to debug over email, but I hope this helps.

Best regards,

--
Aymeric.

[Yo-Yo Ma]

Thanks, Carl. To fix this issue, I had to delete my local git clone of
the django repo, and then clone the github mirror again before
reinstalling. I thought it was due to the /build in the repo, but for
some reason a ``reset --hard`` didn't even fix it, so I'm not sure how
a rm -r then re-cloning did the job, but it did.

[Florian Apolloner]

Cause ``reset --hard`` only resets managed files, not unmanaged files. ``git clean -fdx`` would have done the job (make sure to read the help before issuing that command).

Cheers,
Florian