automatically generating file dependency information from python tools

[John Roth]

"Moosebumps" <moosebumps at moosebumps.com> wrote in message
news:bhFdc.50011$bE2.25447 at newssvr25.news.prodigy.com...
> Say you have a group of 20 programmers, and they're all writing python
> scripts that are simple data crunchers -- i.e. command line tools that
read
> from one or more files and output one or more files.
>
> I want to set up some sort of system that would automatically generate
> makefile type information from the source code of these tools.  Can anyone
> think of a good way of doing it?  You could make everyone call a special
> function that wraps the file() and detects whether they are opening the
file
> for read or write.  If read, it's an input, if write, it's an output file
> (assume there is no r/w access).  Then I guess your special function would
> output the info in some sort of repository, which collects such info from
> all the individual data crunchers.
>
> The other thing I could think of is statically analyzing the source
code -- 
> but what if the filenames are generated dynamically?  I'd be interested in
> any ideas or links on this, I just started thinking about it today.  For
> some reason it seems to be a sort of problem to solve with metaclasses -- 
> but I haven't thought of exactly how.

I'm not entirely clear on what the purpose of this is. I normally
think of "makefile" type information as something needed to compile
a program. This is something that isn't usually needed for Python
unless you're dealing with C extensions. Then I'd suggest looking at
SCons (www.scons.org).

What I'm getting is that you want to tie the individual programs
to the files that they're processing. In other words, build a catalog
of "if you have this kind of file, these are the availible programs that
will process it."

So the basic question is: are the files coming in from the command
line or are they built in? If the latter, I'd probably start out by pulling
strings that have a "." or a "/" or a "\" in them, and examining the
context. Or look at calls to modules from the os.path library.

More than likely you'll find a number of patterns that can be
processed and that will deal with the majority of programs. The
thing is, if you've got a bunch of programmers doing that kind
of work, they've probably fallen into habitual ways of coding
the repetitive stuff.

HTH

John Roth


>
> thanks,
> MB
>
>