modifies deploy configs to accommodate a python-version-schemed deplo…

…y location

deploy/config.common.yml

@@ -1,8 +1,8 @@
 project_name: StoryMapJS
 service_name: "{{ project_name|lower }}"
 gitdeploy_version: "1.0.6"
-python_version: "3.8.2"
-python: /home/apps/sites/StoryMapJS/.venv/bin/python
+python_version: "3.10.2"
+python: /home/apps/sites/StoryMapJS.{{ python_version }}/.venv/bin/python
 service_port: "{{ storymap_port }}"
 nginx_template: storymap.conf
 nginx_client_max_body_size: 20M
@@ -39,11 +39,20 @@ init_env_common:
   PG_PASSWORD: "{{ vault_pg_password }}"
 
 install_root: "/home/apps/sites"
-deploy_dir: "{{ install_root }}/{{ project_name }}"
-application_dir: "{{ deploy_dir }}" # application dir could be a subdirectory
-env_file: "{{ deploy_dir }}/.env"
-envrc_file: "{{ deploy_dir }}/.envrc"
-virtualenv: "{{ deploy_dir }}/.venv"
+
+# We are experimenting with using a project-name symlink to a python-versioned
+# deployment location to facilitate virtualenv builds for python upgrades. Ideally,
+# this means git-deploy would support these concepts orthogonally without resorting to
+# using the application_dir in lieu of the deploy_dir as a path to the environment.
+# For now, since the application dir happens to be the root of the repository, it
+# seems like this will work, but we may want to re-think some of these variables in
+# git-deploy. We may also want to introduce the symlinking as a deployment feature.
+
+deploy_dir: "{{ install_root }}/{{ project_name }}.{{ python_version }}"
+application_dir: "{{ install_root }}/{{ project_name }}" # This actually a symlink not managed by git-deploy
+env_file: "{{ application_dir }}/.env"
+envrc_file: "{{ application_dir }}/.envrc"
+virtualenv: "{{ application_dir }}/.venv"
 project_repo: "[email protected]:NUKnightLab/{{ project_name }}.git"
-requirements_file: "{{ deploy_dir }}/requirements.txt"
+requirements_file: "{{ application_dir }}/requirements.txt"
 wsgi_application: "storymap.core.wsgi:application"