> > Hmm, that depends how you want to structure things. If the different > applications are conceptually different, you can keep them completely > separate by making them separate Django projects; that would give you > the flexibility to put them onto independent URLs, post the source > code to one of them on GitHub and the source to the other on > SourceForge, etc, etc, etc. Alternatively, you can simply have a > single Django application, and then namespace everything using > directories, so people would access http://blah.blah/app1/whatever and > http://blah.blah/app2/whatever to choose what they're doing. > > > Would I look into using vagrant and virtualbox to create an environment > > that would then be loaded onto my linux (home development) server and my > > windows (office) production server to ensure they are the same? > > > > You shouldn't need to, but I would strongly recommend having a > "Staging" server which is as similar as possible to your production > server. It's all too easy to accidentally do something in a > Windows-specific or Linux-specific way if you don't test. (Note that > "Staging" could be actually on the same hardware as "Production", if > you don't have spare funds for a duplicate. Keep your modules separate > using venv, and access them on different URLs; just have some place > where you can quickly check your code under a production-like > environment prior to actually bringing everything down due to a > one-character bug.) > > ChrisA
Thanks. I like the idea of the separate URLs. That way, I guess I could use another framework (e.g. flask), or whatever else if the need ever arose. Also, I could use a very simple front page with links to all of the projects. -- https://mail.python.org/mailman/listinfo/python-list
