If I had to use such scheme, I would put the django application in a package for the target system. Like a .deb file for exemple. If your primary way of deploying is a git push from test/QA to production, split directory will cause plenty of headaches.
Also, with an installation like this, I wouldn't use a virtualenv. By using /usr/local/lib, you are making your application a part of the system. It's like if a standard application was using a non-standard library. I wouldn't expect that. But that's my 2 cents 2016-11-09 8:36 GMT+01:00 Antonis Christofides <[email protected] >: > Hello, > > I was thinking about using this scheme: > /usr/local/lib/projectname > Program files (i.e. repository) > /usr/local/lib/projectname-virtualenv > Virtualenv > /var/lib/projectname/media > Media files > /var/cache/projectname/static > Static files, collected with collectstatic > /var/cache/projectname/cache > File-based cache > /var/log/projectname > Log files > /etc/projectname > Configuration (mostly settings.py) > > I was wondering whether people could find it counter-intuitive, or whether > there could be trouble training new recruits. I understand that some people > are using /opt or /srv or /home, and that it may be common practice to put > the virtualenv, static, and media files inside the repository working > directory. > > My backup script automatically excludes /usr and /var/cache from backup, > so I can decide what shall be backed up just by placing it in the > appropriate directory. This is the main reason I put static files and > file-based cache in /var/cache, and why I dislike schemes where program > files and data are put in a single directory such as /srv/projectname. > So how does the above look to you, and what other practices have you seen? > > (I'm asking primarily because I'm writing a book on Django deployment and > I'm wondering what best practice to propose to the reader.) > > Thanks! > > -- > Antonis Christofideshttp://djangodeployment.com > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/cc2851e9-89cc-3a87-aac6-b0532e5b2233% > 40djangodeployment.com > <https://groups.google.com/d/msgid/django-users/cc2851e9-89cc-3a87-aac6-b0532e5b2233%40djangodeployment.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Cordialement, Coues Ludovic +336 148 743 42 -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEuG%2BTaU-BDeOAXf3iTVk7cLfMdwKSRV1GikFTTq4QxQW1xuPw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
