On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin <and...@aeracode.org> wrote: > > > On 11/06/2010 03:28, Peter Baumgartner wrote: >> >> In my experience, almost every project has domain-specific >> applications that don't get reused. If you have a reusable app, you >> bundle it separately (like South). >> > > I entirely agree, but there's also a lot of domain-specific apps people make > that get used in more than one project. If you're in the business of writing > (say) CMS-backed sites, you're going to have a lot of apps matching that > pattern, and as far as I'm aware, there's no downside to switching away from > having project names in imports. > >> Why do you need to change the Python path at all? Just drop your >> project on the existing Python path and import from there. This is >> easy enough with a symlink or better yet give it a setup.py and >> install it like you would any other Python package. >> > > But that doesn't work. Say I have my nice shiny project "andrewblog". I want > to deploy a staging version and a live version of this on my server. > > If I had local imports, I could just put both projects on the python path / > install them / egg-link them, or whatever. But because they use module names > for imports, if I install one site as a package "andrewblog" and the other > as "andrewblog_staging", say, staging is actually going to be running off of > the live models, URLs, etc, since it has code that goes "from > andrewblog.posts.models import Post".
Why do your two sites need to share the same python path? Virtualenv solves this problem quite gracefully. -- Pete -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
