Well, if I can't fix it it's not the end of the world because it's backed up
with the old name, but I really want to figure out how to go about changing
the project name. Anyway both names are pretty distinctive and extremely
unlikely to occur incidentally in any unrelated strings.
I'll post the traceback below. I removed all pyc files like you suggested.
IT's loading the settings file and choking when it hits the first of my apps
in installed_apps no matter which one that is (i.e., it doesn't matter what
order I put them).
So, how do you go about minimizing project-name dependency, anyway?
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(settings)
File
"/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line
340, in execute_manager
utility.execute()
File
"/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line
295, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 192, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 219, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 348, in handle
return self.handle_noargs(**options)
File
"/usr/lib/python2.5/site-packages/django/core/management/commands/shell.py",
line 18, in handle_noargs
loaded_models = get_models()
File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line
136, in get_models
self._populate()
File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line
57, in _populate
self.load_app(app_name, True)
File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line
72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
ImportError: No module named newname.filebrowser
On Fri, Feb 13, 2009 at 12:06 AM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:
>
> On Thu, 2009-02-12 at 19:45 -0800, stevedegrace wrote:
> > I think I might have bitten off more than I can chew here, heh, and I
> > need some help. I just finished my project and it looks awesome on my
> > computer at home (running Ubuntu Intrepid). But before I deployed it,
> > I decided I didn't like the retarded name I gave the project and I
> > wanted to change it. No problem, I just did this in the project
> > directory:
> >
> > $ find ./ -type f -exec perl -pi -e 's/oldname/newname/g' {} \;
>
> Hmm ... that could have any number of unintended side-effects. Hope that
> string didn't accidentally occur anywhere else.
>
> Just to be safe, I'd certainly make sure I blew away any .pyc files
> after doing the above to make sure they were recompiled correctly next
> time around. In the longer term, I'd work on removing as many
> dependencies on the project name as possible from the code (which should
> be pretty much all of them).
>
> > Worked like a charm,
>
> !?! Presumably you're talking about the kind of chalm one puts on an
> apple before giving it to Snow White, rather than the good kind, based
> on what follows in your mail.
>
> > I've gone through and all the instances have been
> > replaced. Changed the name of my sqlite db instead of changing back
> > the path to the db in settings.py.
> >
> > Only now when I run:
> >
> > $ python manage.py shell
> >
> > or anything like that, it raises ImportError the first time it hits
> > one of my applications in the INSTALLED_APPS list.
>
> It does more than that. It gives you a huge traceback telling you what
> it was trying to import, etc. That information contains the clues about
> what went wrong. In particular, the last line will say something like
> "no module called....". What's it trying to import and what isn't it
> finding that?
>
> > I looked at the
> > code of manage.py and all it seems to do is import settings, it isn't
> > obviously adding the project directory to sys.path. That seems to be
> > the key missing element here. Aside from hacking my manage.py file to
> > make it do what I think it should, how does Django normally figure out
> > how to import project modules?
>
> It just uses the normal Python path, nothing special. The only exception
> is that ./manage.py adds the "current" directory (the one containing
> manage.py) to the Python path so that project-named imports will work
> without people having to learn about Python path. Unfortunate (since it
> hides a problem, not fixes one), but it's not a big deal.
>
> To debug this further, apart from removing the .pyc files, I would also
> copy the source files (or do a fresh checkout if you're using version
> control) to a new directory and try running "syncdb" again. If that
> works, you know the problem is caused by some detritus in the original
> directory. If not, you've eliminated one more thing. Really, though, the
> import error is going to be the place to start: working out why that
> module isn't available.
>
> Regards,
> Malcolm
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
