You have provided me with EXACTLY the information that I requested.
To operate in this mode, I recommend the following:
1) Read enough about Vagrant to be able to "freeze" an image of the VM and use that as a base for your actual work.
That way, you can work through the initial setup of your own customized installation and freeze the result, That way you won't need to repeat those steps every time you want to make a new VM. Then, by working in an expendable copy of the VM, when you "mess up" (and you will :) ), you can just toss it away (vagrant destroy) and start over with a clean copy.
2) Whether you are working in a VM, or directly on your host machine, I strongly recommend the use of virtualenv and virtualenvwrapper. (I like the added functions of the wrapper. But the important concept is the use of the virtual environments)
Virtual environments are like a "poor man's" virtual machine but they don't encounter the overhead of a virtual machine. They allow you to have independent sets of python and python libraries installed. Thus one program can use a different version of a library without affecting other programs.
In my setup, I use a separate virtual environment to represent each logical machine that runs a part of the mailman system.
Thus my mail handler (the "core" part of mailman) is in a separate virtual environment from the web server (postorius).
3) When it comes to development, the various python modules can be divided into three groups.
a) The code that you are developing
b) Other code that is under development but for which you want to use a pre-release version. (or any "source" distribution)
c) Additional library functions upon which those parts depend.
For the vagrant virtual machine organization that you will be using:
Place the (c) routines in /vagrant and keep them under your SCM (version control).
You can have the (b) routines in the home directory on the virtual machine.
The (a) routines will be loaded into the site-packages for the individual virtual environments as a part of the installation process.
If you follow this layout, it will be easy to replace any of the various components whenever you desire.
Since we are new to working with Vagrant, a setup for the mailman project such as I describe is still a "work-in-progress".
Expect some revisions during the summer. However, they should not have any negative impact on your work because all of your code will be stored under the /vagrant mount point and can be moved readily from one virtual machine configuration to the next.
Now, for your code, I recommend that you start by having a separate folder for each of the virtual environments.
In my current setup, I have two virtual environments "VE-mailman" and "VE-webserver".
In your source, you can have:
Of course, depending on just what your project requires, you may not need all of these parts.
Eventually, I would expect to see a setup script that is able to use this layout to automate the building of a suggested installation script.
I hope that this helps.
Feel free to ask questions and make suggestions to improve this setup.
On Jun 15, 2013, at 10:44 PM, Julia Proft <jproft(a)conncoll.edu> wrote:
> Hi Richard,
> this is my first time using virtual machines in development, and I'm figuring it out as I go! Right now, my game plan is to edit on my Windows host, and I'll keep those files in a shared folder that is accessible through the VM... then I can execute the files on the VM.
> On Sat, Jun 15, 2013 at 3:35 PM, Richard Wackerbarth <rkw(a)dataplex.net> wrote:
> Hi, Julia.
> I'm Richard "Wacky" Wackerbarth, one of the Mailman developers and a Mentor for GSoC.
> I notice that, in a discussion on the systems-dev mailing list, you indicated that your host machine is running "Windows 7". Since that is one of the least "Unix friendly" environments, I was wondering just how you utilize the Virtual Machine images in your development cycle.
> It appears that the machines are set up to be "an appliance" (which is great if all you want to do is deploy it). However, using ssh to communicate in a terminal window isn't very friendly for developers.
> So I'm wondering just where you store your code that is under development, how do you edit it, and on what host you execute it?