interesting. What I do for hard-to-please head bangers, like those .cfg files you mention, is I would collect what needs to be updated (an entire section if I have to), find the most efficient way to update/resolve that data, incorporate that in the bootstrap automation. So at install time, the automation would simply read those files, resolve the data, and re-write the entire file (and obviously do the equivalent to other platform if required). This way, a brand new an configured file s available, and without the hassle of tokenizing and updating a few lines in aften large enough files (I just replace the who thing :) )
Since I want to use the same script for all platforms, The first thing to be loaded is a dictionary that contains platform specific properties, which are specifically common within one group of platforms. I.e. a simple check of the OS name being bootstrapped will retrieve the correct values (I.e. 'home','Users','c:/') -> but these are just defaults, I usually leave room to overwrite with a cmd line param or something. On a side note: after thinking about this posting this morning, I decided that a good way to install web2py is to use web2py. There are lots of modules in there that already know web2py and that can be used outside of the web context (scripting). And... there's the DAL :), which would serve as a great place to store/retrive the required data (instead of all those cumbersome text files that carry the automation data). As part of the bootstrap and once deployed correctly, the automation can as a next step, automatically load a web2py APP, if needed, start the server, pass in instructions through XMLRPC or something like that and configure more of the deployment. As an example, and for my own purposes, I would continue the bootstrap to include an import of an up to date csv of a DB that is common to all servers where I need web2py running. Once deployed, all web2py servers are ready for production, in theory :) BTW, I use web2py as part of my build & release system at work (in both in and out of the web context). I made the build system to be portable and installable anywhere, so that developers can use it in non-production activity. So, web2py could potentially be installed and used in hundreds of desktops and laptops at any given time, on any of its supported platforms (and that's outside of production servers). This is why this one-click-deployment effort is of huge interest. If that easily and fully deployed, web2py becomes a great collaboration tool for software development: one app on any computer (and installable anywhere) could easily serve as host to things like code review between developers, or can serve as a quick-to-get-up-and- running means to demo or, this is my favorite, our QA teams can switch there focus from a production server to any developer's computer to download "test" builds, build repports or even large scale test automation if they wanted... and they should be able to do that with there eyes closed because, for them, it becomes just a matter of changing a computer_name or an ip (even half way around the world with VPN as an example). Alright, enough rambling on for me... Thanks, Mart :) On Jan 12, 2:01 am, cjrh <caleb.hatti...@gmail.com> wrote: > On Jan 12, 12:23 am, Christopher Steel <chris.st...@gmail.com> wrote: > > > If people are interested I will clean mine up a bit and post a link to > > the code. > > I rolled out another site yesterday (manually, no script---we use > fabric for successive deployments of the web2py applications, but not > for initial setup). > > Everything goes reasonably smoothly using the HostMonster FCGI > tutorial on web2pyslices, but Sqlite and pysqlite are a huge pain. > If > > ~/local/bin/python setup.py build_static install > > doesn't work for you, then you have to build sqlite manually: > > ./configure --prefix=$HOME/local > make > make install > > Then you have to edit the setup.cfg to point to > > include_dirs=/home/<account>/local/includes > library_dirs=/home/<account>/local/lib > > [Hint: "$HOME" does NOT work inside setup.cfg! Noob error, wasted so > much time on that] > > Then pysqlite will install correctly. > > You may want to incorporate some of these observations into your > script. I have the process down quite efficiently now, if you want > to hear more detail.
