moving existing django projects

[Malik Rumi]

Q: This is a ‘help me understand how this works / what it does’ question rather than a ‘help me I’m stuck’ question. I have an existing Django project I wanted to get on Heroku. I created a new site on Heroku, uploaded my project, and ran migrations. But all I have is a generic new, empty Django site. The Django admin knows nothing about my models. Now, granted, I have not yet put up my existing database but I expected it to at least create the tables for my models, which it did not. Of course they are in installed apps, but I did not run ‘startapp’ since the app already exists. So why didn’t this work? 

Or, should the question be: 'in the case of moving a pre-existing project, what do you do instead of 'startapp''?

Or maybe I have to run startapp anyway? Why?

[Carl Meyer]

Hi Malik,

On 11/12/2014 08:27 PM, Malik Rumi wrote:
> Q: This is a ‘help me understand how this works / what it does’ question
> rather than a ‘help me I’m stuck’ question. I have an existing Django
> project I wanted to get on Heroku. I created a new site on Heroku,
> uploaded my project, and ran migrations. But all I have is a generic
> new, empty Django site. The Django admin knows nothing about my models.
> Now, granted, I have not yet put up my existing database but I expected
> it to at least create the tables for my models, which it did not. Of
> course they are in installed apps, but I did not run ‘startapp’ since
> the app already exists. So why didn’t this work?

I don't know why it isn't working. What WSGI server are you using in the
Heroku deployment? Can you point to the instructions you followed to
deploy your project on Heroku?

> Or, should the question be: 'in the case of moving a pre-existing

> project, what do you do /instead /of 'startapp''?

Nothing. Just migrate.

> Or maybe I have to run startapp anyway? Why?

Startapp is nothing but a convenience to pre-generate a skeleton of some
files; it is precisely and entirely equivalent to creating those same
files yourself in your codebase.

Personally, I never use "startapp" at all, even to create an app in the
first place.

It is certainly not necessary to run it for existing apps on new
deployments.

Carl

[Malik Rumi]

<< What WSGI server are you using in the
Heroku deployment? Can you point to the instructions you followed to
deploy your project on Heroku?>>

Simple questions with not so simple answers. I started with a Django getting started tutorial on Heroku. It had a different look and feel than the rest of Heroku, and it included a sample application called 'getting started'. However, that page has now been completely rewritten to look like all the other Heroku pages, and it no longer includes the tutorial or the getting started project:  https://devcenter.heroku.com/articles/getting-started-with-django#django-settings.

This project used get_wsgi_application from django.core and Cling.

I suspect the reason it's gone now is that there is now an 'official' Django template for getting started on Heroku. It uses whitenoise instead of dj-static and Cling but still has django.core.

Anyway, I adjusted my project to suit these new requirements, then tried adding my pre-existing project which works just fine on my home machine (Windows 8.1), and when that didn't behave as expected is when I came here to post. Since then I have gone ahead and imported my database with pgbackup. Now I understood that this would be 'destructive', but I assumed that meant it would destroy my database, not wipe my models.py too - but that's what it did. Now what I don't get is, if it was so destructive, why is the 'getting started' project now BACK in my Heroku site, (I had deleted it in the first place, and why wasn't it wiped out too in the second place?) and when I run git status or migrate, they both say there are no changes to update, even though my pre-existing models.py is still sitting there on my local dev. I don't get that at all.  

Your wisdom and insights will be greatly appreciated. 

[Carl Meyer]

Hi Malik,

On 11/15/2014 08:52 PM, Malik Rumi wrote:
> << What WSGI server are you using in the
> Heroku deployment? Can you point to the instructions you followed to
> deploy your project on Heroku?>>
>
> Simple questions with not so simple answers. I started with a Django
> getting started tutorial on Heroku. It had a different look and feel
> than the rest of Heroku, and it included a sample application called
> 'getting started'. However, that page has now been completely rewritten
> to look like all the other Heroku pages, and it no longer includes the
> tutorial or the getting started project:
> https://devcenter.heroku.com/articles/getting-started-with-django#django-settings.
>
> This project used get_wsgi_application from django.core and Cling.
>
> I suspect the reason it's gone now is that there is now an 'official'
> Django template for getting started on Heroku. It uses whitenoise
> instead of dj-static and Cling but still has django.core.

django.core.wsgi.get_wsgi_application() gets a WSGI application object,
but you still need a WSGI server to run it. That'll be whatever your
Procfile contains in the "web: " line. Gunicorn is the one shown in
Heroku's docs; is that what you're using?

> Anyway, I adjusted my project to suit these new requirements, then tried
> adding my pre-existing project which works just fine on my home machine
> (Windows 8.1), and when that didn't behave as expected is when I came
> here to post. Since then I have gone ahead and imported my database with
> pgbackup. Now I understood that this would be 'destructive', but I
> assumed that meant it would destroy my database, not wipe my models.py
> too - but that's what it did.

I am quite sure that importing a database using pgbackup did not
actually wipe your models.py file. (It can't; once you've deployed a
version of an app to Heroku all your code is read-only). If you're not
seeing your models in the admin, that's a symptom of a different
problem. Perhaps the wrong settings are being used?

A good place to start would be your Procfile, and the value of
DJANGO_SETTINGS_MODULE you see when you run "heroku config".

> Now what I don't get is, if it was so
> destructive, why is the 'getting started' project now BACK in my Heroku
> site, (I had deleted it in the first place, and why wasn't it wiped out
> too in the second place?)

It seems like you are confused about the distinction between "code
deployed to a Heroku app" and "contents of a Heroku database." If you're
seeing a generic "getting started" app instead of your app, you have a
problem with the former; the latter is irrelevant (for now).

You might start over with a brand new Heroku app (heroku create
somename) and then "git push" your codebase to it.

and when I run git status or migrate, they
> both say there are no changes to update, even though my pre-existing
> models.py is still sitting there on my local dev. I don't get that at all.
>
> Your wisdom and insights will be greatly appreciated.

Carl

[Malik Rumi]

Well, yes, Carl, I am a self taught newby learning all the assumptions, blind spots, and gotchas as I go stumbling through my learning curve. So thank you for your input.

Yes, this is gunicorn. 

<wrong settings?>

Entirely possible. I have another thread going where I learned that Heroku ascribes to 12 Factor, not the One True Way, That is also almost certainly why I keep getting debug toolbar errors on my Heroku installs even though debug is not in my prod settings. that's the subject of yet a 3rd thread. 

<code distinction>

I didn't think I was confused about that, but when I ran into this problem I didn't know what other explanation there could be. 

Here are my console logs:

Wed Nov 12

$ git status

On branch master

Changes not staged for commit:

  (use "git add/rm <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   .gitignore

        deleted:    Cannon/__init__.py

        deleted:    Cannon/gettingstarted/__init__.py

        deleted:    Cannon/gettingstarted/settings.py

        deleted:    Cannon/gettingstarted/static/humans.txt

        deleted:    Cannon/gettingstarted/urls.py

        deleted:    Cannon/gettingstarted/wsgi.py

        deleted:    Cannon/settings.py

        deleted:    Cannon/static/humans.txt

        deleted:    Cannon/urls.py

        deleted:    Cannon/wsgi.py

        modified:   Procfile

Untracked files:

  (use "git add <file>..." to include in what will be committed)

        Baillee/

        static/

        templates/

no changes added to commit (use "git add" and/or "git commit -a")

(Dayton)

<> 

after running git commit and git add:

$ git status

On branch master

nothing to commit, working directory clean

(Dayton)

Sat Nov 15 after running pgbackup:

ls

Cannon     Procfile   reitz template.txt  runtime.txt

manage.py  README.md  requirements.txt    staticfiles

~ $ cd Cannon

cd Cannon

~/Cannon $ ls

ls

gettingstarted  __init__.pyc  settings.pyc  urls.py

__init__.py     settings.py   static        wsgi.py

 

Note Baillee is gone but 'getting started' is back. Now maybe I screwed this up too, and don't know how to make git work, but I did go to the docs before running this.

<start over>

Yes, I will, but I'd still like to understand what happened here so I can diagnose and understand how all these things work better than I do now.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/u6d7eSOvUgk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/546A42DA.3040009%40oddbird.net.

For more options, visit https://groups.google.com/d/optout.

[Carl Meyer]

Hi Malik,

On 11/18/2014 02:32 PM, Malik Rumi wrote:
[snip]

> Here are my console logs:

The console logs certainly suggest that the root of the problem is in
what files you have in git, but there's not much clue why certain files
or directories might be disappearing.

Carl