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',
)
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
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
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >
>>>
>>
>>
>
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.
>>
>
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.)
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.