@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 like a *bad* idea to develop using site- packages....
> If you want to test work flow, then try and make good use of the > "manage.py shell" I have yet to work much with the Django interactive shell but a current project is likely to necessitate it. I am sure it is a useful tool for debugging. Cheers On Dec 22, 2:04 pm, "Cal Leeming [Simplicity Media Ltd]" <[email protected]> wrote: > 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 give some food for thought. > > * Make sure your workflow is sensible for the size of the project > you are working on. For example, there's no point putting > significant time into enterprise grade unit testing, if the app is > not business critical, or the client doesn't want to pay too much. > > * If the project is in-house (i.e. its one of your own projects), > then these are the best times to experiment with new methods and > solutions, because then you are not putting your clients product > at risk, and you learn from mistakes the easy way. (we've all been > there!) > > * It is nice to use isolated Python environments where ever > possible, but remember, they will need to be maintained manually > (for security patches etc). This does have its benefits, for > example if your Django app has dependancies for a specific version > of a module, and the sys admin upgrades Python, and thus breaks > your app. > > * Before you even touch anything, make sure you have a spec from the > client first. This is absolutely crucial if you want an easy life. > Again, if this is your own project, you may choose to either draw > up a spec to give you a good idea as to how one should look > (you'll learn along the way), or think up the spec as you go > along. Some clients will say there is no spec, and that they are > thinking of things off the top of their head. In these cases, you > must *insist* that you work on a daily rate, no exceptions, > otherwise clients will take you for a ride (again, we've all been > there before). > > * It's good to start with the database models first, to make sure > that the underlaying foundations of your application are sound. > Try to anticipate future modifications, and don't bother too much > with tuning to begin with. As long as you have some decent skills > in the database you have chosen to use, then it is an easy enough > task to create indexes along the way etc. > > * 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. I know this sounds like a minimal amount of time saves, > but when you're doing 200-300 test runs a day, it soon adds up! > Again, use your own discretion as to whether this approach is > sensible for the size of the project. > > Also, as a side comment, I haven't used either buildout or fabric, so I > can't offer much advice on these. > > On 22/12/2010 18:40, Dana wrote: > > > 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/staging/ > > production servers > > * PIP -- For installing Python packages into your project. > > * virtualenv -- For creating an isolated Python environment. > > > ... but what I am having trouble figuring out is how the workflow > > should be between these tools. > > > * What's the relationship between PIP and buildout in development vs. > > deployment? > > * Is buildout used solely for installing/packaging stuff for > > deployment? > > * Do you use fabric to run buildout on a server? > > * What role does PIP requirements file play in all this? Is it used? > > * Are you using setuptools or distribute? > > > I know this is a very broad and subjective topic but I'd love to hear > > what you guys and gals are doing out there to develop rapidly and to > > deploy efficiently and predictably. > > > Cheers -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
