I do not know what the best way and retaining the ability to to hot upgrades is important. Just to add a piece of information. Jonathan is working on a re factoring that will allow web2py to be installed in one folder, keep applications/configurations/logs in another, and run from a third folder. This should be done soon and will help in this case.
Massimo On Oct 15, 6:04 pm, Christopher Steel <[email protected]> wrote: > IMHO I would not separate anything. A big part of Web2py's magic is > that you do don't need to "install" it. Keeping everything together > insures that upgrades will always work via the web2py web interface > (with a pleasant side effect being that you do not have to repackage > each time Web2py is updated so you get to spend more time doing what > you love ;) > > Other matters in no particular order... > > If you want "debian" startup scripts you could do it the way you > mentioned, the formal "debian way" or the "web2py" way or some > combination. > > You might consider placing them in the web2py/scripts directory (if > Massimo if OK with that). This would make them easy to update (ie. no > (debian) repackaging required) and they would be available to all > Web2py users and developers. I think web2py/scripts/web2py.ubuntu.sh > has a startup example. I the way it is done in the Ubuntu script work > on all other debian systems. > > Project X > > Project X could be a Debian package containing a "companion" web2py > application. In this case, for Debian users / developers. The idea > being again to free you from the drudgery of repackaging when you (and > optionally others if you so choose) want to update the companion > application. > > I mentioned the possibility of using a mercurial clone as this would > give you the freedom to add additional features, customizations and > updates to the companion application, again without needing to update > any debian packages. It has a lot of other very interesting "side > effects" as well including creating a mechanism (via mercurial) that > allows allows other web2py users to contribute to the application, so > if you chose to do so it could become a web2py community application. > > By "not" automating companion application updates you give package > users "full control". > > Advantages > - Flexibility > - Ability to update the package x companion application without > repackaging. > - Transfer of application maintaining is trivial. > - Others can easily contribute to the package x companion application > by installing package. > - Keeps everyone focused on Web2py. > - Did I mention it is really cool! > > Disadvantages > - Requires maintainers for the two debian packages and one web2py > application. > - Too flexible? > > Universal Installers and so on. > > A setup similar to this opens the door to all the possible things that > one can do with Web2py applications including providing instructions, > links to additional debian packages, apt url installers, chats, > twitter, scripts, server monitoring tools, video instructions, > deployment tools and the list goes up to and including a "Universal > Installer" if one where so inclined. The point being that a Debian > package that including a companion application allows you (or others > if you so choose) to add almost any additional feature at any time > without the need to repackage and redistribute a Debian package, > although this would also be possible if one chose to do so... > > Wow , that was really tough to describe in an email! > > Keep rockin, > > Cheers, > > Chris > > On Oct 15, 1:06 pm, José L. <[email protected]> wrote: > > > On 15 oct, 13:32, Mark Breedveld <[email protected]> wrote: > > > > You have the idea. Thanks for clearing it towards the others. > > > > My guesses it we need to do both. > > > Because Jose goal is general purpose and mine aswell, > > > but comes with overkill in the most cases. > > > > In Jose case I would suggest a slight change. > > > web2py-core > > > web2py-gluon > > > > This has been discusses before, I recall you where in those > > > discussions > > > Jose.http://groups.google.com/group/web2py/browse_frm/thread/45ea4327d713b... > > > >http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb52... > > > > There are some other topics, search for turnkeylinux, where this is > > > mentioned. > > > > I recall Dimo Barsky was busy with packaging Gluon, but I've been out > > > for a while. > > > I don't know him, but he might help with this. > > > > It was chaos post again, but I hope this one helps:p. > > > > Mark, > > > Thanks, but after looking for more info in the links you provided, I > > have not been able to find the rationale > > for a separate gluon and core packages. > > > can anybody enlight me? > >
