gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Random Gump3 questions
Date Wed, 06 Apr 2005 18:15:25 GMT
Hi Adam,

Thanks for your input! This is good stuff.

On 06-04-2005 17:25, "Adam  Jack" <ajack@mric.coop> wrote:
> 1) External PlugIns
> 
> I'd really like to hear design/implementation ideas about
> discovery/life-cycle of plug-ins to Gump3.

My initial idea number one: don't design ahead of need.

> I'd like us to get this sorted
> early to stop us thinking "closed" & allow more contribution. If we can
> implement something (or, better, leverage Python somehow) I'd implement a
> standalone RDF-generating plug-in, for the exercise of it all.

Go for it!

> I think we need to be able to register (e.g. via the workspace, or via
> placing in a certain directory, or whatever) Python code as a plug-in, just
> as simply as we have our own plug-ins. If the code could be discovered,
> loaded, and managed I think we'd be in a good position to allow folks to
> (say) plug-in their own Perforce updater, or builder, or whatever etc.

Hmm. Thinking of a low-tech way to do this...

# somewhere in "main.py"
 pluginpath = os.path.join( '$HOME', '.gump', 'plugins')
 if os.path.exists( pluginpath ):
  sys.path = [pluginpath] + sys.path

And have a file named

 ~/.gump/plugins/config.py

Along with

 ~/.gump/plugins/your-plugin-code.py

You just copy over config.py from the gump distro and edit it to load your
own plugins (I think its the get_plugin() method IIRC).

Step two might be to have a local-config.py which is in some way merged with
the standard gump config.py, so you just override the configuration bits
that you want to override.

> I know this might "stretch" us on getting interfaces (internal APIs) right,
> but I think Gump3 is about trying to get it "right", and this seems a big
> one to me.

I'd prefer having it as a "small" one by leveraging python's features for
this kind of stuff as much as possible :-D. What do you think of the idea
above?

> 2) OnDemand Metadata Loading
> 
> One of the problems with Gump today is it's need to load all the metadata in
> the workspace, to build a huge internal tree, in order to then (say) build
> just a few things. I think it'd make sense to have a more "on demand"
> approach, downloading as needed, to make Gump more "interactive friendly".
> The main use case might be testing (i.e. does Gump w/ this code hack still
> build ant, or does this project/descriptor change still build under Gump)
> but I think these are good use cases.

I agree, but I think it is *really* *really* hard to get right. I'm tempted
to classify this as "next version" feature addition. I dunno. One thing I
would like to experiment with is different algorithms for deciding what to
build and the like, and if the model is changing beneath you that could be
really really difficult to implement. Right now you have a model that's
essentially static from the algorithm POV, simplifying (for example) the
Walker class a whole lot.

> 3) Federation
> 
> Along with (2) I think we need to think more about federation and/or
> delegation. The initial use case might be a site depending upon Apache work,
> but not wanting to duplicate Brutus. As such, I think we need the concept of
> "loading metadata for reference-only verse for processing". Not sure it buys
> us a lot, but I think this is along the lines of (2) above. Meaning, we can
> know that there is a project named Ant, but we might not need to know
> details of it's SCM repository if we aren't going to try to build it.

Hmm. I'm not to worried about sites knowing about stuff, as long as we make
it easy to choose to ignore a lot of that stuff. Right now gump2 has the
choice to specify a list of projects, or defaulting to "all". Maybe we need
to expand that kind of functionality. Yeah, I guess so!

 gump run --federate-with=http://brutus.apache.org/public/ \
    --projects-to-build-from-file=$GUMP_HOME/local-project.list

Or whatever. It seems to me that besides figuring out how a federated site
would want to function, we need to add in the hooks that mark some projects
as "don't build me". We can do the latter with plugins; the former again is
a difficult one :-D

> 4) Repository management.
> 
> I do think we need to have "build from repository" (use last night's
> successful build if today's fails) in Gump3. Any thoughts on where/how this
> might fit?

Yes I do, but haven't found the way to explain it yet. It's on the todo
list. Speaking of which, feel like making jira issues from some of the
above? We've been way to skilled at losing good ideas around here :-D


Cheers,


Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message