class Activity(object):
"""The model of an Activity currently being hacked on.
Version tracking is abstracted by this class as well. Debug control logic
will interact with this.
Generally, this class represents the top-level python package in a given
project. The project may in fact not be a full-blown Sugar activity.
If Develop does not detect the presence of the activity/activity.info file,
the GUI will not present the user with certain Activity-specific features.
Likewise, if the bazaar repository has not been initialised, version
control features will not be presented either.
It is important to note that develop-activity makes a significant departure
from traditional IDE design; it does not persist any sort of "Project"
meta-data between sessions beyond what is stored in the .info file mandated
for Activity Bundles, and the .bzr directory of the Bazaar version
control system. Develop will never touch .bzr directly -- it invokes
bzrlib for all source control operations.
This is done because any sort of Project system would effectively duplicate
the information stored in both the activity.info and version control
facilities. This would mean that the person using this tool would have
"one more thing to worry about". Obviously, this violates the DRY
principle.
As such, I feel reluctant to describe the Develop activity as an "IDE"; it
would be better described as an "Activity Maker" or similar.
New Activities can be created in two ways: as "forks" of existing
activities either from the system image or downloaded from other users
on the mesh (usually done from the View Source key); and newly created
activities.
Activity implements the Factory pattern for Directory objects.
For both technical and usability reasons, there will be no concept of an
"untitled" buffer.
"""