On Saturday 16 June 2007 3:24 pm, Eric Wilhelm wrote:
> Could you please ring-in with "yes that hurts for me too" or "no, you're
> doing it all wrong"?
>
> I'm looking/wishing for a way to munge a file's contents on the way to
> e.g. blib/lib/.  For instance, process_foo_files() would be terribly
> convenient if copy_if_modified() could hit a callback rather than
> File::Copy::copy() *after* creating the basedir and before the chmod.

Oh yeah, that hurts; I -regularly- have need to modify the contents of files 
on their way to blib/lib/.  My context is using M:B as our build system for 
web projects, and we've always got at least one case in each project where we 
need to fix up the "install directory" in a pm file during the build.

> [Note, the chmod makes it inconvenient to do:
>
>   $self->copy_if_modified(from => 'lib/Foo.foo',
>     to => 'blib/lib/Foo.pm') and $self->foo_munge("blib/lib/Foo.pm");
>
> but that's actually a bit wordy, so I still think it hurts elsewhere.]

I agree, that doesn't really do it right.  OTOH, that's about what I've been 
doing; install the files, then come back and (a) figure out their perms, (b) 
chmod the files so they're writable, (c) update the file, (d) put the perms 
back to what they were.

[.....snip.....]
> But that leaves munge_in_place() with the task of open, read, munge,
> open, write vs the much handier sub {s/^#PUT THING HERE/$thing/} usage
> that would be enabled if copy_files() took a "fixup => sub {...}"
> option, right?  Thus, the more common usage might be just:
>
>   $self->copy_files([EMAIL PROTECTED], $to_dir,
>     fixup => sub {s/^#PUT THING HERE/$thing/}
>   );
>
> Where fixup is called as:
>   while(local $_ = <$infh>) {$fixup->(); print $outfh $_}

Mmmmm.... much nicer.  Callbacks are good...

> So now the questions:
>
>   Useful?
>
>   What did I miss?
>    (besides the todo bit "if($^O eq 'os2')" from copy_if_modified())
>
>   Is "fixup => sub {...}" better written as map_lines => sub {...}?

I prefer "fixup" myself, but that's my opinion.

>   What about mixed (e.g. ".pm" and ".cpp" trees)?  Should there be a
>   "where" selector of sorts on the fixup option?  Maybe done as
>   "fixup => {lines => sub {...}, where => sub {...}}" -- this implies a
>   "fixup => {file => sub {...}, where => sub {...}}" which would sort of
>   answer the whole question about after_copy and the three-step thing
>   too.

How about...

a) "fix everything":

        fixup => sub { ... }

b) "fix, but by file glob":

        fixup => {
                "*.pm"  => sub { ... }
                "*.cpp" => sub { ... }
        }

Yes, I'm thinking of allowing -both- options; it should be pretty easy to 
check if you've got a code-ref or a hash-ref.  As for whether "file glob" is 
better than anything else, that's another discussion.  Me, I think that file 
glob is sufficient here, but it could be "extension", "regex", "something 
completely different"...  I just think of it as "some way that you 
differentiate one set of files from another".

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.

Reply via email to