Repository and Directory Structure
Michael
like the settings-local.py solution too. Would an example of that look
like this? :
from django.conf import settings
settings.configure(
DEBUG=True,
TEMPLATE_DIRS=(
'/home/michael/edibles/templates',
)
)
I will try and clear the repo and check in an empty Django project
tonight or tomorrow unless someone beats me to it.
Michael
On Wed, Jul 22, 2009 at 11:18 AM, Rick Flosi<rick....@gmail.com>
wrote:
>> Any thoughts on how we should structure the repository?
>
> This is the structure I've been using for my django projects on webfaction:
>
> UrbanEdibles/
> branches/
> tags/
> trunk/
> django/
> urbanedibles/ (the django project)
> [1 or more django apps]/
> static/
> css/
> img/
> js/
>
> Then I mount django/ at / on the webserver and static/ at /s/.
> The media/ files for django will also need to be setup as well.
>
> I also use a settings-local.py and urls-local.py which import settings.py
> and urls.py and then overwrite the parts needed to make it work locally. I
> imagine people working on the django code will likely want to do something
> similar to develop locally, but we'll probably need files like
> settings-local-rick.py, settings-local-rflosi.py or settings-rflosi.py, ie.
> some more personal naming scheme. Then you just use the settings file when
> running locally.
>
> -r.
Rick Flosi
settings-local.py:
from lpcs.settings import *Basically turn on debugging, set to use urls-local.py, and set the media paths and template directories to my local path.
DEBUG = True
TEMPLATE_DEBUG = DEBUG
ROOT_URLCONF = 'lpcs.urls-local'
MEDIA_ROOT = '/Users/rpf/Work/LPCS/trunk/static/'
DOMAIN = '127.0.0.1:8000'
MEDIA_URL = 'http://%s/s/' % DOMAIN
TEMPLATE_DIRS = (
'/Users/rpf/Work/LPCS/trunk/django/lpcs/templates',
)
urls-local.py:
from lpcs.urls import *And here we serve static content through django so you don't have to setup a local webserver for static files.
urlpatterns_local = patterns('',
# Static files for development server
(r'^s/(?P<path>.*)$', 'django.views.static.serve',
{'document_root': '/Users/rpf/Work/LPCS/trunk/static'}),
)
urlpatterns = urlpatterns_local + urlpatterns
-r.
Michael Bunsen
It seems like everything is just a branch. Should we just make a dir
called django in the default branch? As for static files, I am in
favor of keeping them a separate, unless there are just a few files
that are part of the core site design.
I switched the google code project to a blank mercurial repo. I
started getting my hands dirty with hg tonight. I created a branch
called sandbox to play with, and wrote a quick how-to as I went a
long:
http://code.google.com/p/urbanedibles/wiki/GettingStartedWithMercurial
Also, you are all part of the google group now and can replace your
reply-all's with urbanedi...@googlegroups.com
Michael
On Wed, Jul 22, 2009 at 10:37 PM, mark gross<mark...@gmail.com> wrote:
> but we are not using SVN. Does a tags, branches and trunk directory
> structure make sense when using a DSCM like Hg? (ok I shouldn't be
> asking. it doesn't)
>
> --mgross
>
> On Wed, Jul 22, 2009 at 8:26 PM, Rami Kassab<ra...@typethink.com> wrote:
>> Rick, I'm wondering what the reason is for separating out the static media
>> from the Django project itself? We typically keep it all together. Our
>> typical SVN structure looks like this:
>> /branches/
>> /tags/
>> /trunk/
>>
>> django_project_name/
>>
>> project_files
>>
>> As for local settings, we might just have the app for you. We've written a
>> cool little app called, well, local_settings :) All you need to do is place
>> it in your list of installed apps and then you instantly get over-writable
>> settings. Simply create a python package (a folder with __init__.py) and
>> create .py files named after all the hostnames of the users working on the
>> project. They will automatically get loaded when a dev runs the projects on
>> their machine... based on their hostname. For example, my Mac's hostname is
>> 'Rami's MacBook.local' so I have a .py file within the local_settings
>> directory titled 'ramis_macbook_local.py' (all special characters in the
>> hostname are converted to underscores). In that file I can override whatever
>> settings I want. It's really nifty and easy to use. Let me know if you guys
>> want to include it and use it in the project and we'd be happy to package it
>> up and send it your way. Thanks!
>> --
>> Rami Kassab - Chief Executive Officer
>> M 503.888.8605
>> ra...@typethink.com
>> LinkedIn Profile
>>
>> Typethink - Creative Web Firm
>> P 503.626.6231
>> F 503.626.6233
>> 111 SW 5th Ave., Suite 1000
>> Portland, OR 97204
>> www.typethink.com
>>> On Wed, Jul 22, 2009 at 10:52 AM, Michael Bunsen <not...@gmail.com> wrote:
>>>>
>>>> Hey Mark,
>>>>
>>>> Were you able to get together any model code? I made you and Rick
>>>> owners on the Google code project, so feel free to put anything there.
>>>> I have no attachment to the old code or directory structure that is
>>>> already there.
>>>>
>>>> Hey everyone else,
>>>>
>>>> Any thoughts on how we should structure the repository? We decided to
>>>> try using Mercurial on Google code.
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> On Fri, Jul 17, 2009 at 11:42 PM, Rick Flosi<rick....@gmail.com> wrote:
>>>> > Sounds good. -r.
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > On Jul 17, 2009, at 7:41 PM, mark gross <mark...@gmail.com> wrote:
>>>> >
>>>> >> I think we have a good start. I'll attempt some Django model code and
>>>> >> shoot it past Rick sometime this weekend.
>>>> >>
>>>> >> On Fri, Jul 17, 2009 at 1:01 AM, Michael Bunsen<not...@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Hi All,
>>>> >>>
>>>> >>> Thank you all for coming last Sunday!! I am really excited tackling
>>>> >>> this
>>>> >>> project together. I typed up the database models from our notes and
>>>> >>> Mark
>>>> >>> added the user work flows that we discussed, which are also provide a
>>>> >>> general set of tests or goals that the site will fulfill.
>>>> >>>
>>>> >>> http://wiki.urbanedibles.org/index.php?title=New_Website_Development
>>>> >>>
>>>> >>> There is more we discussed, like our software stack and more specific
>>>> >>> feature ideas, but I am currently on my way into the woods outside of
>>>> >>> Eugene
>>>> >>> and don't have our notes with me. I'll get those up first thing next
>>>> >>> week,
>>>> >>> but feel free to jump on the Wiki -- start an account and add your
>>>> >>> thoughts.
>>>> >>>
>>>> >>> I started a Google Group for development discussion with the address
>>>> >>> urbanedi...@googlegroups.com and directly subscribed those who
>>>> >>> came
>>>> >>> to
>>>> >>> the last meeting. I'd like to keep as much collaboration as possible
>>>> >>> on
>>>> >>> the
>>>> >>> Wiki, or the google code site, but use the list as you see fit.
>>>> >>>
>>>> >>> Here is a roster of those who participated last Sunday:
>>>> >>>
>>>> >>> Rick Flosi - rick....@gmail.com (python & web man)
>>>> >>> Laura Cooper - bunnyl...@gmail.com (pie maker)
>>>> >>> Erin Moore - erm...@pdx.edu - (PSU environmental science)
>>>> >>> Lindsey Walker - lindse...@hotmail.com (mathematics & C
>>>> >>> programmer)
>>>> >>> Mark - mark...@gmail.com (robotics, intel)
>>>> >>> Laurel - lav...@gmail.com (freegeek board member & UE coordinator who
>>>> >>> couldn't make it)
>>>> >>>
>>>> >>> Out next meeting is: Sunday, July 26th @ 3pm at Backspace
>>>> >>>
>>>> >>> Thanks again everyone! Stay in touch.
>>>> >>>
>>>> >>> Michael
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >
>>>
>>
>>
>
Michael Schurter
> True, I can't find a good example of a typical Mercurial / Git schema.
> It seems like everything is just a branch. Should we just make a dir
> called django in the default branch? As for static files, I am in
> favor of keeping them a separate, unless there are just a few files
> that are part of the core site design.
done Django projects in bzr before (would work the same in hg or git):
/ - Root folder where .bzr/.hg/.git directory lives
/README.txt - always need a readme :)
/dev.db - sqlite development db (*not* committed to repo)
/docs - just a place to drop documents or development resources like
diagrams
/fixtures - a place to hold test data for loading into django
/static - for static files, mapped to /static/ in Apache using an
Alias directive
/static/images
/static/js
/static/css - you can guess these :)
/templates - place to keep *all* django templates. i don't like
keeping them in apps
/templates/<app>/<model>_detail.html - an example of a template that
will get picked up by an object_detail generic view
/apps - directory holding all of our apps
/apps/settings.py - main settings file
/apps/local_settings.py - *not* committed, used by devs to override
the default settings
/apps/local_settings.py.template - *is* committed, used by devs to get
sane development defaults
Its not a perfect setup by any means, but imho its an improvement over
just dumping everything into 1 "django project" folder.
HTH. At the end of the day directory structure isn't nearly as
important as code, so feel free to ignore me. :-)
Michael Schurter
@schmichael
Michael Schurter
wrote:
> the default settings
import os
TEMPLATE_DEBUG = DEBUG
'..'))
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = os.path.join(ROOT_PATH, 'dev.db')
MEDIA_ROOT = os.path.join(ROOT_PATH, 'static')
TEMPLATE_DIRS = ( os.path.join(ROOT_PATH, 'templates'), )
SERVER_EMAIL = 'root@localhost' # FIXME
DEFAULT_FROM_EMAIL = SERVER_EMAIL
## And this is how its included in settings.py:
try:
from local_settings import *
except ImportError:
if DEBUG:
print 'No local_settings.py file found.'
import sys
sys.exit(1)
## (The code in the except clause is obviously optional, but it was a
nice reminder for new devs to setup their own local settings)
Michael Bunsen
I say we go a head and create schmichael's tree in the default branch
and start coding. I like keeping the templates grouped together at /
because it makes contribution by designers easier for. Same for
/static
As for complying with the webfaction webapp structure, our deployment
script could export files from the repo where they are suppose to go.
I am still interested in seeing if things will run on App Engine at
some point too.
michael
On Thu, Jul 23, 2009 at 3:26 PM, mark gross<mark...@gmail.com> wrote:
> release management via the DSCM is a good question.
>
> I would think we lay down tags on the good versions and we try to keep
> all mainline development on the master branch (I'm using git
> terminology) But I'm a Hg novice.
>
> I know some folks to ask for advice on this (IRC: pythonpdx or
> pdxpython? and perhaps some mailing lists would be a good idea to ask
> for advice too...)
>
> --mgross
>
> On Thu, Jul 23, 2009 at 8:15 AM, Rick Flosi<rick....@gmail.com> wrote:
>> Mark,
>>
>> On Wed, Jul 22, 2009 at 10:37 PM, mark gross <mark...@gmail.com> wrote:
>>>
>>> but we are not using SVN. Does a tags, branches and trunk directory
>>> structure make sense when using a DSCM like Hg? (ok I shouldn't be
>>> asking. it doesn't)
>>
>> Yeah, you're right. Do we want a place to keep copies of release branches
>> when we deploy to the live server? Or more generally, will deployment be
>> controlled or uncontrolled?
>>
>> -r.
>>
>
Rami Kassab
--
Rami Kassab - Chief Executive Officer
M 503.888.8605
ra...@typethink.com
LinkedIn Profile
Typethink - Creative Web Firm
P 503.626.6231
F 503.626.6233
111 SW 5th Ave., Suite 1000
Portland, OR 97204
www.typethink.com
Michael Schurter
> All, I would recommend you try finding a different host. We have a few
> clients on WebFaction and they're site load considerably slower than sites
> hosted on Slicehost for example. WebFaction has a great setup but their
> network has latency issues in my opinion. Have you guys set your minds on
> WebFaction or are alternatives still open for discussion?
I <3 Linode: http://www.linode.com
I'm sure Slicehost is great as well. I've just never had a reason to
try anything other than Linode.
I'd love to help with sysadmining the server if that kind of help is needed.
As a high profile non-profit site, Linode might cut you a deal too.
Don't hesitate to contact them. They lent me a nice virtual server
for my OS Bridge talk. :-)
(Again, just my $0.02. I think I've heard recommendations and
warnings for just about every hosting company out there.)
Rami Kassab
--
Rami Kassab - Chief Executive Officer
M 503.888.8605
ra...@typethink.com
LinkedIn Profile
Typethink - Creative Web Firm
P 503.626.6231
F 503.626.6233
111 SW 5th Ave., Suite 1000
Portland, OR 97204
www.typethink.com
Michael Bunsen
only good about Linode.
I like how much maintenance and security issues Webfaction takes off
your hands, but I'm willing to go with Slicehost or Linode if you are
willing to help with sysadmining (Michael S).
Our biggest issue is cost. I have been sharing a Slicehost account
that I use for some other small clients. I am willing to pay for a
Shared 1 Webfaction account out of pocket, but probably not a VPS. I
would love if we were able to get a grant or sponsorship for hosting.
I'll try and contact Linode to see what they would offer (good tip
schmichael!)
Rick, sounds like you and I are the Webfaction fans, what are your
thoughts?
There is also App Engine...
Michael
On Jul 23, 5:21 pm, Michael Schurter <michael.schur...@gmail.com>
wrote:
> On Thu, Jul 23, 2009 at 5:15 PM, Rami Kassab<r...@typethink.com> wrote:
> > All, I would recommend you try finding a differenthost. We have a few
Rami Kassab
--
Rami Kassab - Chief Executive Officer
M 503.888.8605
ra...@typethink.com
LinkedIn Profile
Typethink - Creative Web Firm
P 503.626.6231
F 503.626.6233
111 SW 5th Ave., Suite 1000
Portland, OR 97204
www.typethink.com
Michael Schurter
> The main issue with both Slicehost and Linode is the very limited amount of
> bandwidth they offer. As for setting up the machines, I'd be willing to help
> if Michael S. can't. Done that so many times that I can do it in my sleep
> now :)
> Again, I urge you guys to stay away from WebFaction. It's just too damn
> slow. I don't know how Linode is but Slicehost is one of the fastest hosts
> I've ever used... and we've tried a lot trust me. If the price difference
> isn't much between Linode and Slicehost, I'd recommend Slicehost because
> they're backed by Rackspace now, which is a HUGE host. They're also very
> lenient on the bandwidth they allow you. Even if you go over, they wont
> charge you most of the time, which is good for a project like this. It looks
> like Linode gives you a bit more memory than Slicehost does for the same
> price though. The memory for a Django app is important. 256 MB will be JUST
> enough. We've had some smaller sites require more though. So Linode's 360 MB
> plan would suffice for this project.
Linode is lenient on bandwidth too and you can easily upgrade your
account at any time.
If you're going to use Geodjango (which you'll probably want to), it
requires the PostGIS Postgresql extension to be installed. Unless
WebFaction offers that, a VPS is probably your only choice.
Rami Kassab
--
Rami Kassab - Chief Executive Officer
M 503.888.8605
ra...@typethink.com
LinkedIn Profile
Typethink - Creative Web Firm
P 503.626.6231
F 503.626.6233
111 SW 5th Ave., Suite 1000
Portland, OR 97204
www.typethink.com