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 <chris.st...@gmail.com> 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. <jredr...@gmail.com> wrote:
>
> > On 15 oct, 13:32, Mark Breedveld <m.breedv...@solcon.nl> 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?
>
>

Reply via email to