With whom do you guys host with?

[Gunny]

Coming from drupal (www.drupal.org - cms) background (LAMP platform).
TG's 20 minute video geared me to this list. My hosting provider is
1-eurohost.com (shared hosting -- yes i dont have shell access).

Would like to install and test turbogears on my dev. site. But what
should a hosting provider support to run TG, i mean with phpinfo.php i
can check if specific modules are installed / enabled in apache.

Is there any specific way of checking python etc... or how do i go
about it?

thanks,

[Kevin Dangoor]

I'm working on the deployment aspects right now (what good's an app if
you can't stick it out in front of the world, right?)

You can toss a PHP app on just about any server on the net. A CherryPy
app is a little pickier... Regardless, I'd like to make sure that it's
really easy to get a TurboGears app in front of the world.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[Gunny]

I'm glad this aspect is being looked in to. Yes, i certainly agree
that php apps have the advantage of any other language in terms of
hosting. Also, i hardly need to trouble my hosting provider regarding
installing any particular module etc., Even java apps are nowhere near
php as deploying former is not economical.
1-eurohost charges 1-euro/month, definetly not bad for someone trying
to develop/test an app.

[Stephen Day]

Interesting, the forum at TextDrive http://www.textdrive.com has a new
TurboGears category. They must be Gearing up... (sorry for that) :)

[Kevin Dangoor]

On 9/27/05, Stephen Day <sh...@yahoo.com> wrote:
>
> Interesting, the forum at TextDrive http://www.textdrive.com has a new
> TurboGears category. They must be Gearing up... (sorry for that) :)

You better believe I've thought of ridiculous uses of "gearing up" and
"all geared up" :)

Kevin

[Ian Bicking]

Kevin Dangoor wrote:
> I'm working on the deployment aspects right now (what good's an app if
> you can't stick it out in front of the world, right?)
>
> You can toss a PHP app on just about any server on the net. A CherryPy
> app is a little pickier... Regardless, I'd like to make sure that it's
> really easy to get a TurboGears app in front of the world.

I think Paste Deploy has some good potential for making deployment
generally simpler: http://pythonpaste.org/deploy/paste-deploy.html

Basically you make your application a package (done already!), using
setuptools (done too!), and with a special entry point
(paste.app_factory) with the signature:

def make_app(global_config, **local_config):
return WSGI_application

Then deploying the application means installing it (just using
setuptools/easy_install) and creating a configuration for it, like:

[app:main]
use = egg:MyPackage
local_conf1 = foo
local_conf2 = bar

The configuration itself just describes the application instance; right
now you can use that with "paster serve" to serve the application, but
you can also use it for various kinds of indirection. So at work each
site has a file "apps.ini", and it looks like:

[composit:main]
use = egg:Paste#urlmap
/app1 = config:app1.ini
/app2 = config:app2.ini
/login = egg:LoginManager


And each of those "config:filename" sections refers to the application
described by that file, and it dispatches based on URL (virtual domain
is also possible). There's lots of other ways to compose applications
as well, but this is probably the most useful way.

The long-term goal is that an ISP could set up one file like this for
each of their clients, and allow packages to be installed somehow
(probably client-local via ~/.pydistutils.cfg), and each client gets an
application server of some sort (could be paster, but it could be
whatever... the API for getting a WSGI app from a config file is very
simple). I also want to set up a #! line that will turn any config file
into a CGI script, among other things. In general, how the app server
works is something yet to be determined. For instance, supervisor looks
cool for managing it: http://plope.org/software/supervisor/). Or it
would be neat to have a loader that spawns the application in a seperate
process, maybe only on demand -- then seldom-used applications could
take zero resources until they get used, but with some form of caching
so that they stay in memory for a little while once they are used to
avoid the per-request overhead.

Anyway, regardless of features this makes it easy to keep those concerns
separate from the application itself.

--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org

[Kevin Dangoor]

On 9/28/05, Ian Bicking <ia...@colorstudy.com> wrote:
> I think Paste Deploy has some good potential for making deployment
> generally simpler: http://pythonpaste.org/deploy/paste-deploy.html
>
> Basically you make your application a package (done already!), using
> setuptools (done too!), and with a special entry point
> (paste.app_factory) with the signature:
>
> def make_app(global_config, **local_config):
> return WSGI_application
>
> Then deploying the application means installing it (just using
> setuptools/easy_install) and creating a configuration for it, like:
>
> [app:main]
> use = egg:MyPackage
> local_conf1 = foo
> local_conf2 = bar
>
> The configuration itself just describes the application instance; right
> now you can use that with "paster serve" to serve the application, but
> you can also use it for various kinds of indirection. So at work each
> site has a file "apps.ini", and it looks like:
>
> [composit:main]
> use = egg:Paste#urlmap
> /app1 = config:app1.ini
> /app2 = config:app2.ini
> /login = egg:LoginManager

I've seen the discussions on web-sig (and Phillip's article about SCALE).

When using CherryPy, it's quite natural to compose things through
standard Python means. As in this contrived example:

from logins import LoginManager

class Root(controllers.Root):
login = LoginManager()

This is really a question of where one prefers to keep configuration:
in config files, or in Python.

> And each of those "config:filename" sections refers to the application
> described by that file, and it dispatches based on URL (virtual domain
> is also possible). There's lots of other ways to compose applications
> as well, but this is probably the most useful way.
>
> The long-term goal is that an ISP could set up one file like this for
> each of their clients, and allow packages to be installed somehow
> (probably client-local via ~/.pydistutils.cfg), and each client gets an
> application server of some sort (could be paster, but it could be
> whatever... the API for getting a WSGI app from a config file is very
> simple). I also want to set up a #! line that will turn any config file
> into a CGI script, among other things. In general, how the app server
> works is something yet to be determined. For instance, supervisor looks
> cool for managing it: http://plope.org/software/supervisor/). Or it
> would be neat to have a loader that spawns the application in a seperate
> process, maybe only on demand -- then seldom-used applications could
> take zero resources until they get used, but with some form of caching
> so that they stay in memory for a little while once they are used to
> avoid the per-request overhead.

supervisor looks neat. Thanks for the link!

Python and tools like pastedeploy really provide so many ways to
manage things (that are all lighter and easier than their Java
equivalents), it's a wonder all that hoopla sprung up about Java being
the "enterprise" solution.

> Anyway, regardless of features this makes it easy to keep those concerns
> separate from the application itself.

This is true. For a large portion of people, though, I'm not sure that
this separation of concerns is needed. Luckily, it's entirely possible
to offer both ways of composing an app: through pastedeploy and
standard cherrypy/python means...

Kevin

[Ian Bicking]

Kevin Dangoor wrote:
>> [composit:main]
>> use = egg:Paste#urlmap
>> /app1 = config:app1.ini
>> /app2 = config:app2.ini
>> /login = egg:LoginManager
>
>
> I've seen the discussions on web-sig (and Phillip's article about SCALE).
>
> When using CherryPy, it's quite natural to compose things through
> standard Python means. As in this contrived example:
>
> from logins import LoginManager
>
> class Root(controllers.Root):
> login = LoginManager()
>
> This is really a question of where one prefers to keep configuration:
> in config files, or in Python.

Well, phrased that way, I'd rather keep my configuration in
configuration files ;)

paste.deploy doesn't take the place of all the ways you'd want to
compose an application -- if you *always* want one app to hang off
another, then it's best done in Python. However, if I have to edit
someone else's code just to add an app that will make me most unhappy.
Of course, I could create a site-local dummy CherryPy app that just
forwarded to other apps (assuming they are all CherryPy apps to), but
that's quite a big heavier than the configuration file.

The goal of paste.deploy isn't to take over everything. But it does
allow a separation where appropriate. Simply from a software
development point of view that separation usually becomes apparent -- if
you are making modifications to an app that you don't want to commit,
because they aren't universable applicable, then it's probably
"configuration", and paste.deploy addresses a certain class of
configuration well.

My hope is that paste.deploy will allow a little of what PHP allows --
that someone who isn't a programmer and maybe knows nothing about Python
can install and configure an application, and that hosting companies can
provide good support for this process.

>>Anyway, regardless of features this makes it easy to keep those concerns
>>separate from the application itself.
>
>
> This is true. For a large portion of people, though, I'm not sure that
> this separation of concerns is needed. Luckily, it's entirely possible
> to offer both ways of composing an app: through pastedeploy and
> standard cherrypy/python means...

Sure -- the only thing paste.deploy needs is an entry point, which isn't
exclusive of any other means of deployment or configuration. Well...
AFAIK CherryPy still has limited WSGI support (only one CherryPy WSGI
app per process), but I hope and assume that will be resolved. But
that's a separate issue... paste.deploy requires good WSGI support, and
good WSGI support is useful irregardless of paste.deploy.

[Scott Benjamin]

Has there been any progress on an "offical" deployment scenario?

I'd like to throw up some turbogears apps on my site, which doesn't
allow fastcgi, and I'm wondering what my options would be.

Also, I just found Turbo Gears last night, stayed up for 3 hours longer
than I should have just looking and finding my way around. Well done
indeed!

Scott

[Scott Benjamin]

Whoops.. just after I posted that I found this:
http://www.turbogears.org/docs/deployment.html

heh..

Thanks,

Scott

[Kevin Dangoor]

Yeah, that document is woefully inadequate, but will get you
somewhere. The non-root installation instructions I just sent, plus
using mod_proxy (ProxyPass/ProxyPassReverse) or mod_rewrite should get
you a chunk of the way there.

Kevin