Ignore changes in the amount of whitespace
Differences between version dated 2003-12-09 21:50:14 and 2010-01-12 21:21:04
(spanning 6 versions)
Deletions are marked like this.
Additions are marked like this.
#pragma section-numbers off
Up: IntroToPeak Next: IntroToPeak/LessonTwo
= Basic Configuration =
= Lesson One: Commands and Configuration =
'''Contents'''
[[TableOfContents]]
== Introduction ==
also be made executable with `chmod +x helloworld` if you're
using a Unix-like OS, as opposed to just a Unix-like shell.)
(Unfortunately, the format of `#!` lines is extremely non-portable.
The example we gave above will work on BSD-ish Unixes, which pass
all of the arguments on a `#!` line separately. For other operating
systems, you may need to use the `invoke` program, as described
on the IntroToPeak main page.)
Python still needs imported modules to be on the
`PYTHONPATH`, though, so you have to call this `helloworld`
file like this: {{{
#!/usr/bin/env peak runIni
[peak.running]
app = importString('helloworld:HellowWorld')
app = importString('helloworld:HelloWorld')
[helloworld]
message = "Hello, world!"
}}} Hmm, what's that output redirection? Doesn't print normally
write to `stdout`?
Indeed, it does. And `stdout` is normally the shell command's
`stdout`, and certainly is in our little application here. But an
`AbstractCommand` can be run in many environments, not just from a
shell script the way we are doing here. So to future-proof our
code, we use the facilities `AbstractCommand` provides for communicating
with its environment, whatever that may turn out to be.
(In addition to `self.stdout`, `AbstractCommand` also provides
`self.stdin`, `self.stderr`, `self.environ`, and `self.argv`.)
Indeed, it does. And `self.stdout` for an `AbstractCommand` is
normally the same as Python's `sys.stdout`; certainly this is
so for our application here. But an `AbstractCommand` can be
run in many environments, not just from a shell script. For example,
in a later lesson we'll run this very same `HelloWorld` application
as a service over a TCP/IP socket. If we wrote a simple `print`
statement, it would be harder to reuse our command object.
So, when writing a command object, we use `self.stdin`, `self.stdout`,
`self.stderr`, `self.environ`, and `self.argv` to obtain the files
and values that a standalone program would obtain via the `sys` and
`os` modules. This allows our command objects to be composed into
larger commands within a Python program, almost as though we were
building Unix pipelines within a single process.
So, again, we can run our program at this point and get the same
Anyway, we can run our program again at this point, and get the same
results as before. But we still haven't '''used''' the configuration
information. To do that, we need the `binding` package, to "bind"
an attribute of our application to a configuration variable.
== Binding attributes to configuration ==
Specifically, we will use the `Obtain` class from the `peak.binding`
== Points to Remember ==
Before we move on to the next chapter, let's recap the concepts we've covered so far:
Before moving on to the next lesson, let's recap the concepts we've covered so far:
* Running applications
* The return value of an executed function (or `_run()` method) will become the exit code for the entire program, when it is run by the `peak` script.
* `_run` implementations should use the variables provided in `self` to communicate with their environment.
* `_run` implementations should use the variables provided by `self` (`stdin`, `stdout`, `stderr`, `argv`, and `environ`) to communicate with their environment. In this way, commands can be reused by other commands in a manner similar to Unix pipelines, but inside the same Python program.
* Configuration files
