I've been bashing my head against a wall lately trying to determine
the best (highly subjective, I know) workflow for developing Django
projects.
What I have gathered so far is:
* Buildout -- For building and packaging your projects.
* Fabric -- For easy deployment/testing of code on devel/stagin
Hi
After working on couple of big projects I felt the best way to start on
django once you have the basic setup ready is
1.) Have a complete list of the features into your requirement documents
if its not possible and you want a agile development methodology split
into features that makes sen
Subramanyam, thanks for the response.
In regard to 3, I am not clear why it would be a good idea to add in
model fields for things you *think* you might want some day.
I would think that using Django South or something similar to create
SQL migrations for your model after a change would be a clea
Dana ...
How you build and deploy your project will be shaped by the environment
where you're deploying. Thus my choices about "best practices" will be very
different that yours. That said, here are my thoughts (worth exactly what
they cost you):
- You're definitely right about using South
hi Dana
On Thu, Dec 23, 2010 at 12:51 AM, Dana wrote:
> Subramanyam, thanks for the response.
>
> In regard to 3, I am not clear why it would be a good idea to add in
> model fields for things you *think* you might want some day.
>
> I would think that using Django South or something similar to
Apologies if I have repeated what anyone else has said, or if some of
these comments aren't directly related, but here's my two cents worth.
And remember, rapid development isn't always about the different pieces
of software or frameworks that you use, so hopefully some of the below
comments g
> * If you want to test work flow, then try and make good use of the
> "manage.py shell" and also the ability to create management
> commands. This will allow you to quickly test code changes,
> without having to do app restarts, or going through login
> processes.
Cal
Sure thing.
In several previous projects, they required the user to upload a file
via the browser (usually above 10mb), and this was then sent off into
the queuing system to be processed. Now, because of the huge amounts of
time it took to upload, we instead created a management command, which
Thanks, Cal -- that's extremely helpful.
On Dec 22, 5:42 pm, "Cal Leeming [Simplicity Media Ltd]"
wrote:
> Sure thing.
>
> In several previous projects, they required the user to upload a file
> via the browser (usually above 10mb), and this was then sent off into
> the queuing system to be proc
@Subramanyam
> South is a good tool, but my point is its better not to get to the point
> that we have to use South.
Why do you think South is a fallback rather than part of your toolset?
>From what I can see it is a great tool and adds a lot of great
features to a Django developers arsenal.
On
@Carl
I agree that virtual environments are very useful. I would argue they
are almost essential in a Python/Django project. I'm starting to
wonder if there are compelling reasons NOT to use a virtualenv when
developing, especially one that is so isolated as a "--no-site-
packages" one. It seems l
hi
On Fri, Dec 24, 2010 at 10:32 AM, Dana wrote:
> @Subramanyam
>
> > South is a good tool, but my point is its better not to get to the point
> > that we have to use South.
>
> Why do you think South is a fallback rather than part of your toolset?
> From what I can see it is a great tool and ad
12 matches
Mail list logo
