gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@TrySybase.com>
Subject RE: [RT] gump.py
Date Sun, 13 Apr 2003 19:11:05 GMT

	I do envision all code to be in Python.  However the future I see most
	likely is that the code that does a build (for example) would neither
	directly access the original workspace definition nor would this be code
	generated.

I agree a cache or database as a local working definition is valuable
(especially as module definitions are more distributed). I like that you are
thinking about batch and non-batch modes of operation, however I would like
to discuss the latter somewhat. I'm not arguing against, I am just curious..

If the premise of gump continues to be "the latest from CVS with everything
updated, or with some locally installed packages" what is the purpose of a
non-batch mode Gump? I suspect most folks in development will build a
package in eclipse (or other IDE) against what packages they have. (I just
don't see them wanting to have "the latest up to this minute" given the
overhead of that.) As such -- is non-batch operation intended for gump
config debugging, or for build debugging, or?

Just curious & trying to see through other's eyes...

regards,

Adam

BTW: What comes to my mind is gump helping with "keeping the build
environment up-to-date". Much as something like Ruper (or other) could keep
built packages up-to-date, I see gump as managing (by building)
dependencies.


Mime
View raw message