Closed ajparsons closed 4 years ago
One issue might be that it won't create the new venv while the previous exists. So that might need to be deleted first.
We could make $virtaulenv_dir
configurable, or just change it in the PR so a completely new one is created.
I've updated that shebang and pointed all the references to the virtualenv to a new venv folder. That will mean we can roll backwards if it goes wrong easily enough as well.
OK, I think that looks good.
We can try deploying from this branch before merging as a test, we don't have a staging environment. We could set one up if we think its worthwhile - would that be something you'd use?
Depends how much work it is? I'm rarely making giant changes at this point so I'd say probably not necessary, but you'd be in a better place to see the advantages.
Quick notes:
Need to reconcile the httpd.conf in the repo and the servers/vhost file. Then likely to need to make a change to that to refer to new location of venv folder (and possibly python version).
Those are now reconciled.
I've undone this merge. Can get past the markitup problem by removing it as an INSTALLED_APP, but then run into more generic error after deployment, so reverted to previous master.
Addresses #32, updates repository to Python 3 and Django 2.2.8.
Works fine in the local vagrant (now using stretch). One issue might be that it won't create the new venv while the previous exists. So that might need to be deleted first.