"from foolscap import api"

[Brian Warner]

The collection of API calls that are currently exported in foolscap/__init__.py are difficult to handle: it is easy to wind up with circular imports. I'd like to provide foolscap/api.py instead, and have applications pull everything from there. This is a big change, since to really fix things we need to empty foolscap/__init__.py. So I'd like to add api.py in one major release and then remove the symbols from __init__.py in the next.

The immediate goal is to add api.py to the next (0.3.3) release, with all the symbols that are currently in __init__.py, as well as the useful symbols that are not (fireEventually, some of the constraint definitions, some more exception types).

[Brian Warner]

[0b0b9fb18d1f49766eb0153d410db55eeaa6de49] starts this process. The next step is to release 0.3.3 and make sure that Tahoe can do everything it wants through just foolscap.api . Then we'll add wrappers around the functions/classes defined in __init__.py to emit deprecation warnings if they're ever used, and release 0.4.0 . Then we can empty out __init__.py__.

Of course, if I get impatient, I might do this sooner..

[Brian Warner]

0.4.0 introduced foolscap.api, but has no deprecation warnings

[Brian Warner]

[72bbe49fb768dcdc0c521b2bf4191093f36aa4bf] added the deprecation warnings. The next release (0.5.0) will include them.

[Brian Warner]

moving this ticket to 0.6.0: the next implementation phase will be to empty out foolscap/__init__.py

[Brian Warner]

[89ee821572a223f43a88bb1abdc4f155c60f7f7d]/[89ee821572a223f43a88bb1abdc4f155c60f7f7d] finishes this, by emptying out __init__.py (and removing deprecated.py. I for one welcome our new foolscap.api overlords.