Switching between release and trunk.

[Dave Warnock]

Hi,

I want to develop/run TurboGears applications using the releases. But on
the same machine I want to be able to test them against the trunk and
potentially contribute to the trunk.

If I understand http://www.turbogears.org/community/contributing.html
correctly then to use the trunk version I

a) checkout turbogears trunk from svn

b) run "python setup.py develop" on the checked out copy

c) when I run any project that imports turbogears it now uses the
checked out copy

Once I have done this how do I go back to a live application and run it
on the released version of TurboGears?

Thanks

Dave

[Elvelind Grandin]

take a look at http://peak.telecommunity.com/DevCenter/EasyInstall#changing-the-active-version-site-packages-installs-only

--
cheers
elvelind grandin

[bon...@gmail.com]

personally, I would use a multiple "non-root" setup. Something like
this :

~/trunk/bin/python

~/stable/bin/python

Then ~/trunk/lib/python2.4/site-packages will store the head version of
everything, not just Turbogears. Likewise for ~/stable

I can run either version by choosing the python I run.

[Ian Bicking]

You can usually just easy_install the old version, and it will change
the .pth files but otherwise not install anything new.

If TG has some sort of require option that could be invoked early, then
you could use a different invocation to require the version of TG that
you want to use. This would be a nice feature for the scripts that
easy_install installs in general -- right now they require a fixed
version, but if they (say) checked an environmental variable for a
version override that would be cool. Then you could support multiple
versions running at once (each in its own process, of course).

(And incidentally with Paste you'd do paster --plugin=TurboGears==0.5
serve ..., or include the version number in your app's install_requires,
or in your Paste Deploy configuration file.)

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

[Dave Warnock]

Ian,

> You can usually just easy_install the old version, and it will change
> the .pth files but otherwise not install anything new.

Ok, but the next point is more what I want (I don't want to take down
the intranet just because I want to work on the trunk for a while).

> If TG has some sort of require option that could be invoked early, then
> you could use a different invocation to require the version of TG that
> you want to use. This would be a nice feature for the scripts that
> easy_install installs in general -- right now they require a fixed
> version, but if they (say) checked an environmental variable for a
> version override that would be cool. Then you could support multiple
> versions running at once (each in its own process, of course).

Yes, please. Should I create a ticket?

> (And incidentally with Paste you'd do paster --plugin=TurboGears==0.5
> serve ..., or include the version number in your app's install_requires,
> or in your Paste Deploy configuration file.)

As per the blog discussion I think getting TurboGears working fully with
paste is important for deployment. I understand it requires 2 things

a) cherrypy change as per your ticket item 145
http://www.cherrypy.org/ticket/145 "Running multiple apps in one process"

b) integration of turbogears tg-admin into paste. It sounds as if this
is done by duplication rather than extension at the moment - can that
change so they stay synchronised automagically?

Thanks

Dave

[Ian Bicking]

Dave Warnock wrote:
>>If TG has some sort of require option that could be invoked early, then
>>you could use a different invocation to require the version of TG that
>>you want to use. This would be a nice feature for the scripts that
>>easy_install installs in general -- right now they require a fixed
>>version, but if they (say) checked an environmental variable for a
>>version override that would be cool. Then you could support multiple
>>versions running at once (each in its own process, of course).
>
>
> Yes, please. Should I create a ticket?

Well... I'm not sure what the right project would be. Obviously you can
for TG, but I think the change should really happen in setuptools.

I think the patch would probably be simple. There's two wrappers -- one
from the standard distutils method, and one from the console_scripts
entry point. The one TurboGears uses looks like:

#!/usr/local/bin/python
# EASY-INSTALL-ENTRY-SCRIPT:
'TurboGears==0.8a1dev-r39','console_scripts','tg-admin'
__requires__ = 'TurboGears==0.8a1dev-r39'
import sys
from pkg_resources import load_entry_point

sys.exit(
load_entry_point('TurboGears==0.8a1dev-r39', 'console_scripts',
'tg-admin')()
)


Just change that so it looks like:

#!/usr/local/bin/python
# EASY-INSTALL-ENTRY-SCRIPT:
'TurboGears==0.8a1dev-r39','console_scripts','tg-admin'
import sys, os
__requires__ = os.environ.get('TURBOGEARS_REQUIRE',
'TurboGears==0.8a1dev-r39')
from pkg_resources import load_entry_point

sys.exit(
load_entry_point(__requires__, 'console_scripts', 'tg-admin')()
)


I don't know that $TURBOGEARS_REQUIRE is the best name, but something
like that. I'm not sure how easy it is to set environmental variables
in Windows, but on Posix systems you'd then just need to do:

TURBOGEARS_REQUIRE='TurboGears==0.5' tg-admin ...

>>(And incidentally with Paste you'd do paster --plugin=TurboGears==0.5
>>serve ..., or include the version number in your app's install_requires,
>>or in your Paste Deploy configuration file.)
>
>
> As per the blog discussion I think getting TurboGears working fully with
> paste is important for deployment. I understand it requires 2 things
>
> a) cherrypy change as per your ticket item 145
> http://www.cherrypy.org/ticket/145 "Running multiple apps in one process"

Yes; from here a paste.app_factory entry point could be added to
TurboGears and/or CherryPy, and/or new projects (ultimately the cleanest
method is when a new project contains a native entry point).

> b) integration of turbogears tg-admin into paste. It sounds as if this
> is done by duplication rather than extension at the moment - can that
> change so they stay synchronised automagically?

Well... the API for a paster command is fairly simple. You make an
entry point of type paste.paster_command, and the object that the entry
point points to has to be callable with one argument (the name that was
used to invoke it, generally the entry point name) and returns an object
with a .run(args) method, which returns a integer exit code, or raises
paste.script.command.BadCommand. Oh, and they should also have a
summary attribute, a (possible empty) description attribute, and a
group_name attribute -- all used for the help display. So, I imagine a
wrapper for the current TurboGears commands would be easy enough, and
since it's just entry points it doesn't mean TurboGears will require
PasteScript, just work with it.

Templates are another API, paste.paster_create_template. Template
objects are also instantiated with their name, and have a method
.run(output_dir, vars), where vars is a dictionary of extra arguments
provided on the command line, plus two standard ones: 'package' and
'project'. For --list-templates they also have a name attribute and a
summary attribute. And I suppose they should have a group_name and
description attribute, but that's not used yet. Oh, and a .egg_plugins
attribute, which is a list of plugins that are later enabled (it
probably be ['TurboGears'], or maybe ['TurboGears', 'SQLObject']).

So I think it would be pretty easy to support both commands (tg-admin
and paster) at once.

[Dave Warnock]

Hi Ian,

>> Yes, please. Should I create a ticket?
>
> Well... I'm not sure what the right project would be. Obviously you
> can for TG, but I think the change should really happen in
> setuptools.

> I think the patch would probably be simple. There's two wrappers --
> one from the standard distutils method, and one from the
> console_scripts entry point. The one TurboGears uses looks like:

Are you willing and able to follow this up in setuptools, I may be
willing but lack the able part :-)

>> As per the blog discussion I think getting TurboGears working fully
>> with paste is important for deployment. I understand it requires 2
>> things
>>
>> a) cherrypy change as per your ticket item 145
>> http://www.cherrypy.org/ticket/145 "Running multiple apps in one
>> process"
>
>
> Yes; from here a paste.app_factory entry point could be added to
> TurboGears and/or CherryPy, and/or new projects (ultimately the
> cleanest method is when a new project contains a native entry point).

Ok hopefully that will get fixed soon in CherryPy.

>> b) integration of turbogears tg-admin into paste. It sounds as if
>> this is done by duplication rather than extension at the moment -
>> can that change so they stay synchronised automagically?

<snip>

> So I think it would be pretty easy to support both commands (tg-admin
> and paster) at once.

Sorry but I got lost and focused on this sentence ;-) Is that code
changes in both projects or only one?

Thanks.

Dave

[Kevin Dangoor]

Catching up on email I missed...

On 10/6/05, Dave Warnock <dw-it...@warnock.me.uk> wrote:
> > I think the patch would probably be simple. There's two wrappers --
> > one from the standard distutils method, and one from the
> > console_scripts entry point. The one TurboGears uses looks like:
>
> Are you willing and able to follow this up in setuptools, I may be
> willing but lack the able part :-)

I think that a special command line flag might be more convenient than
an environment variable for choosing the version. Phillip may have
thought of that more, though.

Following up on this for setuptools basically means raising the issue
on distutils-sig. Now that we have an issue tracker up, I think that
it's good to track anything we care about in there as well.

> >> a) cherrypy change as per your ticket item 145
> >> http://www.cherrypy.org/ticket/145 "Running multiple apps in one
> >> process"
>

> Ok hopefully that will get fixed soon in CherryPy.

I haven't seen anyone talking about it at all on the cherrypy list.
Maybe everyone has been content to write their own blog software every
time :)

> >> b) integration of turbogears tg-admin into paste. It sounds as if
> >> this is done by duplication rather than extension at the moment -
> >> can that change so they stay synchronised automagically?
>
> <snip>
>
> > So I think it would be pretty easy to support both commands (tg-admin
> > and paster) at once.
>
> Sorry but I got lost and focused on this sentence ;-) Is that code
> changes in both projects or only one?

I believe that what Ian meant is that tg-admin can still exist as a
wrapper around paster (and other things). So, the paster project
creation routine would do the work, rather than the current tg-admin
quickstart. I'm generally in favor of that, but the only drawback is
that it adds a dependency on Cheetah.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

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

[Ian Bicking]

Kevin Dangoor wrote:
> Catching up on email I missed...
>
> On 10/6/05, Dave Warnock <dw-it...@warnock.me.uk> wrote:
>
>>>I think the patch would probably be simple. There's two wrappers --
>>>one from the standard distutils method, and one from the
>>>console_scripts entry point. The one TurboGears uses looks like:
>>
>>Are you willing and able to follow this up in setuptools, I may be
>>willing but lack the able part :-)
>
>
> I think that a special command line flag might be more convenient than
> an environment variable for choosing the version. Phillip may have
> thought of that more, though.

An environmental variable is orthogonal to the rest of the command line,
so it's easy from that perspective. Otherwise I suppose the command
line would have to rewrite sys.argv if it found a special versioning
option? It's complex, where an environmental variable is easy. At
least on Posix systems, I don't know how easy it is to locally set an
environmental variable on Windows.

>>>>a) cherrypy change as per your ticket item 145
>>>>http://www.cherrypy.org/ticket/145 "Running multiple apps in one
>>>>process"
>>
>>Ok hopefully that will get fixed soon in CherryPy.
>
>
> I haven't seen anyone talking about it at all on the cherrypy list.
> Maybe everyone has been content to write their own blog software every
> time :)

I added an extra note to the ticket, simply that I care about it.

>>>>b) integration of turbogears tg-admin into paste. It sounds as if
>>>>this is done by duplication rather than extension at the moment -
>>>>can that change so they stay synchronised automagically?
>>
>><snip>
>>
>>>So I think it would be pretty easy to support both commands (tg-admin
>>> and paster) at once.
>>
>>Sorry but I got lost and focused on this sentence ;-) Is that code
>>changes in both projects or only one?
>
> I believe that what Ian meant is that tg-admin can still exist as a
> wrapper around paster (and other things). So, the paster project
> creation routine would do the work, rather than the current tg-admin
> quickstart.

Well, actually that you could support tg-admin at the same time as
paster, in that wrappers to make the current command objects into paster
commands (using entry points) would be fairly easy. At that point
tg-admin and paster will do the same thing, but will be two separate
script frontends. From there you could rewrite tg-admin to use the
paster frontend (using paste.script.command.run()), I suppose with some
tweak to the create command to imply --template=turbogears; though I
dont think tg-admin would otherwise be any different than the paster
command, as once you set up a project paster is completely customizable.

> I'm generally in favor of that, but the only drawback is
> that it adds a dependency on Cheetah.

Paste Script (I think in 0.3, and definitely in the trunk) doesn't
strictly require Cheetah. That is, only PasteScript[Cheetah] will bring
in a Cheetah requirement.

However, even with the changes to Kid to allow non-HTML template output,
I still think Cheetah is better for this kind of file generation. So I
think it has a useful place. And it installs from PyPI just fine right
now. But that only matters if you use paste.script.copydir; otherwise
the templating can copy over files however it wants.

Ian

[Kevin Dangoor]

On 10/9/05, Ian Bicking <ia...@colorstudy.com> wrote:
> An environmental variable is orthogonal to the rest of the command line,
> so it's easy from that perspective. Otherwise I suppose the command
> line would have to rewrite sys.argv if it found a special versioning
> option? It's complex, where an environmental variable is easy. At
> least on Posix systems, I don't know how easy it is to locally set an
> environmental variable on Windows.

True that an environment variable is easier. On Windows, I'm always
running cygwin anyhow, so I generally do things the unixy way there.
But, I believe you can just set VARIABLE=foo on one line and then run
the command on the next.

> Well, actually that you could support tg-admin at the same time as
> paster, in that wrappers to make the current command objects into paster
> commands (using entry points) would be fairly easy. At that point
> tg-admin and paster will do the same thing, but will be two separate
> script frontends. From there you could rewrite tg-admin to use the
> paster frontend (using paste.script.command.run()), I suppose with some
> tweak to the create command to imply --template=turbogears; though I
> dont think tg-admin would otherwise be any different than the paster
> command, as once you set up a project paster is completely customizable.

Ahh, I see. Yes, that makes sense.

>
> > I'm generally in favor of that, but the only drawback is
> > that it adds a dependency on Cheetah.
>
> Paste Script (I think in 0.3, and definitely in the trunk) doesn't
> strictly require Cheetah. That is, only PasteScript[Cheetah] will bring
> in a Cheetah requirement.
>
> However, even with the changes to Kid to allow non-HTML template output,
> I still think Cheetah is better for this kind of file generation. So I
> think it has a useful place. And it installs from PyPI just fine right
> now. But that only matters if you use paste.script.copydir; otherwise
> the templating can copy over files however it wants.

Oh, thanks for the clarification. That sounds pretty easy to work with.

The trouble with Cheetah is that it's *very slow* on Windows unless
you have namemapper.pyd, and it's not nicely packaged for Windows.
Cheetah doesn't go through too many updates, though, so I could always
package up an egg and be done with it.

I haven't tried Kid's non-HTML output to decide on that one yet. I do
know that doing TurboGears quickstart with just Python's built in
string templating worked just fine. If quickstart were to start
growing options, then that basic templating would fail. (Of course, if
it grows lots of options, it won't be so "quick" for the user any
more...)

Kevin

[Ian Bicking]

Kevin Dangoor wrote:
>>>I'm generally in favor of that, but the only drawback is
>>>that it adds a dependency on Cheetah.
>>
>>Paste Script (I think in 0.3, and definitely in the trunk) doesn't
>>strictly require Cheetah. That is, only PasteScript[Cheetah] will bring
>>in a Cheetah requirement.
>>
>>However, even with the changes to Kid to allow non-HTML template output,
>>I still think Cheetah is better for this kind of file generation. So I
>>think it has a useful place. And it installs from PyPI just fine right
>>now. But that only matters if you use paste.script.copydir; otherwise
>>the templating can copy over files however it wants.
>
>
> Oh, thanks for the clarification. That sounds pretty easy to work with.
>
> The trouble with Cheetah is that it's *very slow* on Windows unless
> you have namemapper.pyd, and it's not nicely packaged for Windows.
> Cheetah doesn't go through too many updates, though, so I could always
> package up an egg and be done with it.

An egg shouldn't be too hard. Also, it doesn't have to be terribly fast
if it's just used to generate files, not serve.

> I haven't tried Kid's non-HTML output to decide on that one yet. I do
> know that doing TurboGears quickstart with just Python's built in
> string templating worked just fine. If quickstart were to start
> growing options, then that basic templating would fail. (Of course, if
> it grows lots of options, it won't be so "quick" for the user any
> more...)

I feel you have to work pretty hard to make it slow enough to matter. I
really am not using any Cheetah features quite yet, just string
substitution, but then it turned into slightly more complex substitution
(e.g., allowing ${repr(version)}), and I want to use the same techniques
for deployment, and more complex templating (i.e., ifs) are more likely
for generating configuration files and whatnot.

Ian