We just released the whole PyF 2.0 stack.
A big change in this release is that we decided to synchronize the
releases of all the layers of the framework:
With this change we hope to be able to more effectively keep the API
changes in sync along the stack, as well as make it more clear which
versions of which components are compatible. As a rule, we chose to
have the first 2 numbers of each release to be synchronized, and use
an eventual third number for bugfix releases, just like Gnome does for
example. Plugins don't follow this convention. For now, we want to be
more lax with them and let them evolve at their own pace. We also feel
that not pressuring plugin developers to follow a strict release
process might encourage third parties to create more plugins, making
for a more lively PyF ecosystem.
This is also the first release to include a stable documentation.
Until now, the documentation was closer to the development trunk than
the actual stable releases. The documentation for 2.0 is available at
We also added a bunch of unit tests and fixed all those that were
failing. PyF is stil far from 100% coverage, but this is nevertheless
a first step in the right direction. In a framework composed of
several layers, keeping the APIs in sync is of the utmost importance,
and unit tests are possibly the only way to achieve that.
PyF now uses the setuptools "extras_require" directive to allow
installing different levels of PyF, along with the appropriate
- if you want the thrill of doing everything on the low level:
$ easy_install pyf
$ easy_install pyf[minimal]
- if you like the ability to use XML networks with default plugins:
$ easy_install pyf[components]
- and if you need a full-blown web application, tube designer along
with all default plugins:
$ easy_install pyf[fullstack]
If you installed pyf from the bootstrap script, updating is simple,
just type this in your virtualenv:
$ easy_install -UZ pyf[fullstack]
We now support multiprocessing: each node of the network can be in its
own process. Of course, this introduces some message passing overhead
and as such it is not always more efficient, so a judgement call must
be made for each application on a case-by-case basis. Note that this
is probably still a bit rough, and will no doubt be refined over the
next releases. To easily test this, you will find a new "advanced"
expandable panel on your components in the tube designer, expand it
and select the "separate process" checkbox.
Components saw a rather drastic change: through a metaclass, they now
all inherit the configuration of their parent components. The same
metaclass also automatically documents the configuration keys of the
components. Yay for more docs!
PyF.Services is now based on TurboGears 2.1 instead of the alpha/beta
as previously. We strongly recommend that you migrate your
PyF.Services applications to TurboGears 2.1. Migration should be
pretty straight-forward, don't hesitate to ask for help on the mailing-
list or on IRC.
Tube parameters (enclosed in the <params> tag) were drastically
improved. We now support more params types such as boolean, select and
radio buttons. Multi-select is on its way, but it requires some
invasive changes to the core of PyF.Componentized and as such we
preferred delaying it for next release. Params can also be visually
grouped in fieldsets. This allows making the launcher form more
visually appealing, but it doesn't change the params behavior. We
realize that as of now this is still an undocumented feature and we'll
make sure to properly document it. If you want to see it done sooner,
patches are obviously welcome. ;)
We also fixed a lot of bugs both in the stack and in existing plugins,
but let's not make this email even longer. If you want all the gory
details, go read the Mercurial logs for each module. :)
Best regards, and happy coding,
The PyF Team !