how to setup a paver dev environment?

[Jack Kuan]

Hi,

first of all, I just like to say thank you for coming up with a tool
like Paver,
I've always wanted something in Python similar to what Ant provides to
the Java world, and Paver looks really neat.

Last night, I grabbed the source using the command:

bzr branch http://bazaar.launchpad.net/~dangoor/paver/main

and then in the 'main' directory, I did:

python ./bootstrap.py

and it started downloading and installing some packages, but finally I
got:
...
Processing virtualenv-1.0-py2.5.egg
creating /home/kjkuan/Projects/paver/main/lib/python2.5/site-packages/
virtualenv-1.0-py2.5.egg
Extracting virtualenv-1.0-py2.5.egg to /home/kjkuan/Projects/paver/
main/lib/python2.5/site-packages
Adding virtualenv 1.0 to easy-install.pth file
Installing virtualenv script to /home/kjkuan/Projects/paver/main/bin

Installed /home/kjkuan/Projects/paver/main/lib/python2.5/site-packages/
virtualenv-1.0-py2.5.egg
Processing dependencies for virtualenv
Finished processing dependencies for virtualenv
./bin/python: can't open file 'setup.py': [Errno 2] No such file or
directory


and I can't find the setup.py or related files in the 'main'
directory.

I've played a bit with paver0.4(grabbed from the .tar.gz file), and
modified Bunch to add string interpolation, so you can do things like:

options(
opt1 = "some value",
opt2 = 1234,
opt3 = "$opt1 = $opt2",
opt4 = "I've got $opt3 here",
sub_opts = Bunch(
opt1 = "a tree of options...",
opt2 = "give me more!",
more_opts = Bunch(
opt1 = "${/opt2}... here we go!",
even_more_opts = Bunch(
opt1 = "${../../opt3}!!!!!"
)
),
opt3 = "let's see what $../opt4"

),
opt5 = "this is a $sub_opts/opt1 $sub_opts/opt2",
opt6 = "$sub_opts/more_opts/../../opt2",
)

but now I just want to get the latest paver directly from the main
branch and see if I can integrate my changes with it. Could you help
me?

Thanks again,
Jack

[Kevin Dangoor]

Hi Jack.

Try updating and giving it another try.

Bootstrapping is now a little more complicated because Paver used to
have a traditional setup.py, but it now uses the new generated
setup.py (so Paver really does use Paver for its own build.)

(More comments below)

On May 1, 2008, at 11:49 PM, Jack Kuan wrote:

> first of all, I just like to say thank you for coming up with a tool
> like Paver,
> I've always wanted something in Python similar to what Ant provides to
> the Java world, and Paver looks really neat.

Thanks!

Docs are my next step and I hope to get those together soon and get
another proper release out.

> I've played a bit with paver0.4(grabbed from the .tar.gz file), and
> modified Bunch to add string interpolation, so you can do things like:
>
> options(
> opt1 = "some value",
> opt2 = 1234,
> opt3 = "$opt1 = $opt2",
> opt4 = "I've got $opt3 here",
> sub_opts = Bunch(
> opt1 = "a tree of options...",
> opt2 = "give me more!",
> more_opts = Bunch(
> opt1 = "${/opt2}... here we go!",
> even_more_opts = Bunch(
> opt1 = "${../../opt3}!!!!!"
> )
> ),
> opt3 = "let's see what $../opt4"
>
> ),
> opt5 = "this is a $sub_opts/opt1 $sub_opts/opt2",
> opt6 = "$sub_opts/more_opts/../../opt2",
> )
>
> but now I just want to get the latest paver directly from the main
> branch and see if I can integrate my changes with it. Could you help
> me?

The new bootstrap should help. I should also note that if you want a
traditional 'develop' environment for Paver, you currently need to do
this:

python bootstrap.py
bin/paver minilib generate_setup
sudo python setup.py develop

As far as the string interpolation goes, the first thing I'd like to
do there is if the option you're looking up is callable, call it. So,
you'd do this:

opt3 = lambda: options.foo

That should be trivial to add. And the reason I'm keen on that rather
than string interpolation at this particular point in time is that it
lets you return ints, lists, Bunches, etc.

Ian Bicking had suggested to me a couple weeks ago that using an
actual template language in config files is quite handy. If/when Paver
grows the ability to read a config file format as an option (Python is
always the standard), I can see using a template engine like Tempita
rather than simple string interpolation.

Also, you'll want to check out the new namespace stuff in 0.5. That
may influence the idea of doing ../../foo types of things to get to
other options.

(BTW, I will say that everything is still open for discussion at this
point... the previous stuff about lambda and Tempita is just my
current line of thinking...)

Thanks for the input and for getting involved!

Kevin

[Jack Kuan]

Hi Kevin,

Thank you. After updating again, the bootstrapping works now. I'll
need to spend some time to see how everything's put together by Paver.
Looks like it integrated quite a few things that I'm not familiar
with.

About your idea of calling an option value if it's callable, I think
it's a great idea(why didn't I think of that!! well, at least I had
fun with string interpolations :). I'll also look into the new
Namespace thing for option lookups.

As for using other kind of file format instead of python, and speaking
as someone who has written quite a bit of Ant XML build files(with all
kinds of extensions enabled, even with jython), I really hope we would
never need to do that... . But, I do hope that if we integrate some
kind of preprocessing to pavement.py, we should at least make it
possible to choose different template engines since not everyone has
the same taste in template engines.

Thanks,
Jack

[Kevin Dangoor]

On May 2, 2008, at 11:57 AM, Jack Kuan wrote:

> Thank you. After updating again, the bootstrapping works now. I'll
> need to spend some time to see how everything's put together by Paver.
> Looks like it integrated quite a few things that I'm not familiar
> with.

Feel free to ask about anything that's not clear. Part of the
documentation I plan to do for the release is docstrings and such in
the code.

> About your idea of calling an option value if it's callable, I think
> it's a great idea(why didn't I think of that!! well, at least I had
> fun with string interpolations :). I'll also look into the new
> Namespace thing for option lookups.

Cool.

> As for using other kind of file format instead of python, and speaking
> as someone who has written quite a bit of Ant XML build files(with all
> kinds of extensions enabled, even with jython), I really hope we would
> never need to do that... . But, I do hope that if we integrate some
> kind of preprocessing to pavement.py, we should at least make it
> possible to choose different template engines since not everyone has
> the same taste in template engines.

My attitude is definitely that I want Python as my build tool
language, because I always have the language features I need to do
whatever dynamic bits I need to do. However, I could see people liking
the concise, clean INI file syntax for common, declarative-style
tasks. We'll see, though. It's not something I intend to really think
about any time soon.

Kevin

[jhermann]

On May 2, 5:49 am, Jack Kuan <kjk...@gmail.com> wrote:
> I've always wanted something in Python similar to what Ant provides to
> the Java world, and Paver looks really neat.

The real counter-parts in the Java world are Gant and Gradle (and
they're potential projects to get inspired from ;). Especially the
latter has the same ability as Paver to mix declarative and imperative
paradigms.

[Kevin Dangoor]

On May 20, 2008, at 9:17 AM, jhermann wrote:

> The real counter-parts in the Java world are Gant and Gradle (and
> they're potential projects to get inspired from ;). Especially the
> latter has the same ability as Paver to mix declarative and imperative
> paradigms.

Thanks for the pointers. I had never seen Gradle before.

Kevin