Yeah, we can put a script inside the image (e.g. like ~/start_allura). I like that idea.
I think for today I'll just keep everything as-is though. Maybe during PyCon sprints I'll work on a script. On 4/3/14 10:42 AM, Cory Johns wrote: > Ugh. Of course update.sh won't be there if the repo is missing, but I > meant having some sort of script in the VM image that handles checking out > the repo and running the setup steps (including update.sh). Alternatively, > could be a wrapper script that handles cloning the repo and initializing > the VM (similar to ievms). > > > On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <[email protected]> wrote: > >> +1 for shared folder, as well, but could we possibly make update.sh handle >> the git clone from the vagrant side if the code is missing? >> >> >> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <[email protected]>wrote: >> >>> +1 shared folder. Like Tim said, it is what people who are used to >>> developing with Vagrant expect. FWIW I've also never felt the shared >>> folders in Vagrant were slow. >>> >>> >>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <[email protected]> >>> wrote: >>> >>>> +1 for leaving shared folder setup as is >>>> >>>> >>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh < >>>> [email protected] >>>>> wrote: >>>> >>>>> FWIW, I would leave the shared folder setup as-is. I use this vagrant >>>>> setup regularly for other projects and I've never noticed a >>> performance >>>>> penalty - it's always felt as responsive as accessing local files. I >>>> would >>>>> think people kind of expect this setup when using vagrant (if they've >>>> used >>>>> it before anyway). And if we change it, we'll only end up replacing >>> the >>>>> `git clone` instructions with nfs mount or rsync instructions. >>>>> >>>>> >>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote: >>>>> >>>>>> I'm working on building a new vagrant image, since the last image we >>>>> built was >>>>>> back in August. Our instructions [1] specify doing a git clone of >>> the >>>>> repo (and >>>>>> I actually missed that and got tripped up by lack of source!). But >>>> would >>>>> it >>>>>> make more sense to include the git repo within the machine image? >>>> That'd >>>>> make >>>>>> it easier to get up and running (especially if you don't have git >>>>> installed on >>>>>> the host). Code getting stale wouldn't be an issue since our Vagrant >>>>>> instructions specify to run update.sh (http://update.sh) which >>>> includes >>>>> a git pull. >>>>>> >>>>>> The downside is that the allura source wouldn't be in a shared >>> vagrant >>>>> folder >>>>>> for easy access with your favorite editor, it'd have to be edited >>> with >>>>> vim >>>>>> inside the vagrant box. But shared vagrant folders are pretty slow >>>>> anyway, so >>>>>> its probably better to recommend development via a different shared >>>>> method >>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2]. >>>>>> >>>>>> A different option would be to recommend downloading an official >>>> release >>>>> instead >>>>>> of git clone. >>>>>> >>>>>> Yes? No? >>>>>> >>>>>> [1] >>>>>> >>>>> >>>> >>> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ >>>>>> [2] >>>>> >>>> >>> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines >>>>>> >>>>>> -- >>>>>> Dave Brondsema : [email protected] (mailto:[email protected]) >>>>>> http://www.brondsema.net : personal >>>>>> http://www.splike.com : programming >>>>>> <>< >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
