Oh yeah, and the biggest thing: Thanks you guys! You're awesome. Now to
figure out deploying the site on WebFaction with mod_wsgi :)
On Fri, Feb 13, 2009 at 1:18 AM, Stephen DeGrace <degr...@gmail.com> wrote:
> LOL I'm an even bigger idiot than you guys think :). At the end of the
> operation when I was changing the name of the directory itself I confused
> myself with a symlink and changed the name of the symlink, not the real
> directory. Changed the name of the directory, problem go bye bye. Weird eh?
> Anyway, I won't try that again, although it was interesting. Can you believe
> I did not know you didn't have the use the project name in imports. I went
> through my entire project and got rid of the project name in imports.
>
>
> On Fri, Feb 13, 2009 at 12:43 AM, Stephen DeGrace <degr...@gmail.com>wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
