Add some capability to reset project folder to scratch.

[changeling]

Perhaps a --reset option in setup.sh, or a separate reset.sh script.

Functionality to remove node_modules and python_env. Either rotate or remove backend/geneaprove.log. Perhaps strip the various __pycache__ directories.

[changeling]

For what it is worth, I'm using this little script I threw together for the purpose.

Note that I'm currently leaving python_env intact for the manage.py operations.

Note also that I'm using a modified settings.py which changes DATABASES to place the geneaprove.sqlite file in the top-level of the backend/ directory.

Note also that I'm running this in a copy of the geneapro git directory, and copying the original migration files from there.

# Clear node files
rm -rf node_modules;

# Remove all __pycache__ files and directories.
find . -path "*/__pycache__/*" -delete;

# Remove migrations.
find . -path "*/migrations/*.py" -not -name "__init__.py" -not -path "*/python_env/*" -delete;

# Change to backend/ directory.
cd backend/;

# Remove database.
rm geneaprove.sqlite;

# Replace project migrations.
cp -r ~/Desktop/python_playground/geneapro/backend/geneaprove/migrations/*.py geneaprove/migrations/;

# Update the migrations.
./manage.py makemigrations;

# Run migrations.
./manage.py migrate

[briot]

Note also that I'm running this in a copy of the geneapro git directory, and copying the original migration files from there.

Clear node files

rm -rf node_modules;

Remove all pycache files and directories.

find . -path "/pycache/" -delete;

Remove migrations.

find . -path "/migrations/.py" -not -name "init.py" -not -path "/python_env/" -delete;

That part seems wrong. Migrations are part of the sources, and that’s how the database is created and populated initially.

Remove database.

rm geneaprove.sqlite;

There shouldn’t be a sqlite file there (it is supposed to be created in a system-specific place, like ~/Library on MacOS)

Update the migrations.

./manage.py makemigrations;

Run migrations.

./manage.py migrate

I would not run those here personally. These last two steps are already executed as part of the ‘setup.sh’ script, so the cleanup script should really be about cleaning things, but not recreating them.

[changeling]

That part seems wrong. Migrations are part of the sources, and that’s how the database is created and populated initially.

This sequence is a generally accepted practice for resetting a django app to database zero during development (See, for example: https://www.techiediaries.com/resetting-django-migrations/):

# Remove migrations.
find . -path "*/migrations/*.py" -not -name "__init__.py" -not -path "*/python_env/*" -delete;

# Remove database.
rm geneaprove.sqlite;

# Update the migrations.
./manage.py makemigrations;

# Run migrations.
./manage.py migrate

Note that I am replacing the deleted initial project migrations from the github master clone, because as you said, they are part of the source and I am using a copy of that master directory as a working environment before making changes in a git branch.

At the moment, the only migration actually deleted is backend/geneaprove/migrations/0005_auto_20180424_1545.py which is created upon running ./manage.py makemigrations; ./manage.py migrate.

This line handles replacing the deleted migrations with the originals from the master directory:

# Replace project migrations.
cp -r ~/Desktop/python_playground/geneapro/backend/geneaprove/migrations/*.py geneaprove/migrations/;

As I'm using this script from within my working directory, that line is actually doing:

cp -r ~/Desktop/python_playground/geneapro/backend/geneaprove/migrations/*.py ~/Desktop/python_playground/geneaprove.working/backend/geneaprove/migrations/

The git clone in my environment is:

~/Desktop/python_playground/geneapro

and my working copy is:

/Users/clarson/Desktop/python_playground/geneaprove.working

There shouldn’t be a sqlite file there (it is supposed to be created in a system-specific place, like ~/Library on MacOS)

As I mentioned in my notes in the previous message, I've moved it to the root level of backend for my own development. This is for my own preference, particularly during development in my .working directory, and not something I'm including within my git repo.

I'm curious why you say it is supposed to be in a system-specific place, though? Is this a design decision of yours, perhaps for use by other apps, or for the production release of geneaprove? That's not typical practice with django in my experience, and clutters up ~/Library/Application\ Support/ with development files.

I would not run those here personally. These last two steps are already executed as part of the ‘setup.sh’ script, so the cleanup script should really be about cleaning things, but not recreating them.

As it stands, setup.sh is missing the ./manage.py makemigrations; and so doesn't implement the files in backend/geneaprove/migrations/. I've added that in my working copy, and would be happy to issue a pull request for the change:

(
   cd backend
   dir=`./manage.py showconf | grep dir= | cut -d= -f2`
   mkdir -p "$dir"
   ./manage.py makemigrations
   ./manage.py migrate
)

Though perhaps this could simply be done in the tmux.sh script by replacing:

tmux split-window             "source python_env/bin/activate; cd backend; ./manage.py migrate; ./manage.py runserver 8002"

with:

tmux split-window             "source python_env/bin/activate; cd backend; ./manage.py makemigrations; ./manage.py migrate; ./manage.py runserver 8002"

While I'm working on something in a development setting, I like to do everything I can to reset to initial conditions periodically just to be sure. But you're correct in that I could alter the script to leave 0001_initial.py, 0002_auto_20180314_0957.py, 0003_initial_data.py, 0004_create_p2p_type.py as well as the already ignored __init__.py, and just delete the (currently only auto-created additional migration file) 0005_auto_20180424_1545.py.

I took the delete-and-replace approach in case future upstream (you! 😀) work added other migrations.

[briot]

Interesting comments, thanks. I know very little of django in practice, so any advice on the subject is welcome. I use only a very tiny part of it, and what I use (the ORM) I keep fighting with :-)

Would you contribute a pull request for this cleanup, and (if you are interested) for the initial setup too (where to put the database, how to build a production package,...). That is, if you are familiar with Django ?