User:ReD Fox/GSOC 2007 Installer

From BlenderWiki

Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Google Summer of Code 2007 Proposal

This is an alternative, though similar, proposal to the repository proposal. Though similar in goals and even in some concepts, this proposal focuses solely on the Blender side of things. The advantages to this approach (over the other) include:

uses existing systems (less future maintenance)
provides something that Blender users can immediately use from within Blender
will contribute directly to Blender's development
provides better opportunity for multiple external CVS repositories

Project Title

Blender python script management system

Synopsis

The goal of this project will be the completion of a script management system for use within Blender. The system will allow the user to browse through registered scripts, perform simple organizational tasks, remove scripts, install new scripts (both those saved locally and those residing in remote CVS repositories), and, for scripts installed from a remote repository, update existing scripts when a new version becomes available.

Benefits to the Blender Community

Currently, the management of python scripts happens on a level that is not intuitive to new users, and that is somewhat cumbersome to even the advanced users. If you wish to add functionality to Blender via a new script, you must locate the script online, download it, locate the appropriate scripts directory on the system, and copy/extract the new script to that directory (in a way that all of the files end up where they should be). If you wish to have more control over how the script appears in the menus (e.g. would like to change the script's menu name or the menu group it resides in), you are required to edit the source file's header. As mentioned, most or all of these tasks are cumbersome at best, and can be difficult for the new Blender user.

Integrating a single, well-documented script into Blender that manages these basic functions will help users manage their scripts more quickly and effectively. Additionally, it will open the door to the creation of central, online repositories that will further benefit the Blender python community.

Deliverables

1. A python script manager/installer with the following features:

Users can view and browse the current list of visible scripts.
Users can perform basic management functions on installed scripts (such as change their menu locations and names).
Users can safely remove/uninstall scripts from their environment.
Users can install scripts that are stored locally (.py file, archive, or directory).
Users can browse and install scripts from selected remote CVS repositories.
Scripts that are installed by the script installer will be tracked (including those from CVS repositories).
When a new revision is available, users will be notified and given the option to update scripts installed from a CVS repository.

2. A set of documents and documented standards, including:

A basic (but complete) manual for the script installer.
Standards for a method for a packaged script to instruct the installer where the package's files are to reside relative to the appropriate scripts directory.
Standards for methods of associating meta-data with scripts in CVS.

Project Details

The proposed python script for Blender will enable users to install, remove, manage, browse, download, and update Blender python scripts - all from within Blender. The creation of a script that includes some of this functionality is already being developed by this proposal's author [1]. However, the features of this script only include the ability to browse and manage scripts: they do not include installation, uninstallation, or interfacing with CVS systems.

Feature Details

The goal of this project is to extend the script currently in development to support the following features:

1. Full script management.

By altering script headers, the user can have full control over how and where the script appears in Blender's menus. The script currently under development [1] only supports changing the menu group location. It should be extended to allow the user to alter the script name and tooltip as well. 2. Script installation.

Once the user has acquired a script, the script installer/manager should allow them to select the script, and, if possible, should copy the script's files to the appropriate Blender scripts directory. In addition, it will allow the user appropriate control over the (pre)installation process so that they can verify the files to be installed and correct any file conflicts. Also, the installer will track the installed files by storing necessary information (including file backups of the files the installation replaced). This information will be used in the future by both the installation and uninstallation processes.

3. Script uninstallation.

This feature will allow the user to, as safely and cleanly as possible, remove previously installed scripts. It will allow the user to verify which files are to be removed and (where relevant) whether backups are to be restored. It will remove the selected files, restore backups when safe and appropriate to do so, and update the meta-data to reflect the changes.

4. Integrated python CVS client

This will be the most difficult and intensive part of the project. But it also will allow some very exciting opportunities to be made available in the future. With this script I will include a basic CVS client. Unfortunately, even after a fairly intensive search, I could not find a useable, generic python CVS client, so this part of the project will need to be extensively researched and, probably, coded from the ground up. There is an almost-working python CVS client, PyCVS [2], that I may be able to port to this project. Initially, the client only needs to support anonymous, read-only access to a CVS repository, which should simplify some things. I will take steps to create this as an independent module, enabling it to be used in other projects, and ensuring that a clear interface is defined in the script installer so that support for other types of repositories (such as SVN) can be added in the future with minimal fuss.

In addition to the script installer, I intend to write a basic user manual for the script (for publication on the wiki), and will need to define and publish a set of standards for two main areas:

1. Directions for script installation.

It would be very helpful if scripts were distributed with machine-understandable installation directions to assist in placing the correct script files in the correct locations relative to the scripts directory. This will be researched, documented and published, and support for such a system will be added to the installer. This may take the form of additional info in the script's header, a separate (parseable) file, or even a specially formed python script (such as the way "setup.py" is used in python). Ways will be researched (though probably not incorporated) for more advanced operations such as defining dependencies or allowing the user to set per-script configuration options during installation.

2. Defining meta-data for scripts in CVS.

Raw CVS access is nice, but it does not lend itself well to a catalog-type system that is easy to browse through and locate specific files based on varied criteria. Because of this, in order to help the user filter through large CVS repositories of python scripts, standards and methods will be researched and published that define how to organize a script repository and how to store both global and per-script meta-data within the repository.

User Experience

Careful attention will be given to ensure that the user experience and interface is as simple, but powerful, as possible, and that the script looks and acts as much like Blender as possible. In the script under development [1], for instance, the script uses Blender's theme colors for its own, fits to the window, uses a custom wheel-mouse/scroll-bar scrolling interface, and attempts to follow a consistent, from-the-top-down and left-to-right work flow. Other interface considerations have also been made (such as hotkeys and various display helps), and I do not intend to compromise on this quality while extending this script to include the features outlined in this proposal. Additionally, reasonable defaults will be defined, the installation/uninstallation/update routines will perform as transparently to the user as possible, and advanced, potentially confusing options (CVS connection details, for instance) will be encapsulated and either placed beneath a level of abstraction (such that the user may need to invoke a dialogue) or in a place and manner that does not distract from basic, normal work flow.

A few use-case scenarios for reference:

1. The user wants to change a script's menu location from 'Mesh' to 'Object', and wants to modify the script's name (as it appears in the menus).

The user invokes the "Script manager" (the script outlined in this proposal) from a menu, and is presented with a list of all installed scripts. Path 1 - They select the option to order the list by menu group, and scroll down until they locate the scripts in the 'Mesh' group; Path 2 - They select from a pull-down menu to only display scripts in the 'Mesh' group. The user locates the script within the 'Mesh' group they wish to modify, and, via a pull-down menu, change the assigned 'Mesh' group to become 'Object'. They then click on the text field containing the script name, and change it to the name of their preference. Optionally - the user clicks on a "refresh" button, and notes that the script is no longer listed in the 'Mesh' group. The user browses to the 'Object' group and notes that the script is listed correctly. The user exits the script manager, opens a menu in Blender, and notes that the change has been successfully completed.

2. The user would like to install a script they have recently downloaded.

The user invokes the script manager from a menu, and is presented with a list of all installed scripts. They skip over all of this and locate and click on an "install" button towards the bottom of the window. A file selector opens, and they browse, locate, and select the file they wish to install (an archive containing multiple files, including documentation and demo files). After selecting the file, the user is presented with a list of the archive's files separated into three blocks (main scripts, file conflicts, and additional files) for classification. Noting that there is a highlighted statement in the "main scripts" block informing them that "There are no registered python scripts available for this script; a python script must be registered before installation can continue" (the python script in the archive does not contain a BPY header), the user toggles the "register" button on the python file listed in the "additional files" block. Immediately, the file is transferred to the "main scripts" block, and the user is able to easily enter the header information into labeled text fields. Additionally, the user notices that there are two files, "readme.txt" and "important.txt", listed in the "file conflicts" block. They toggle the "install" button to 'off' for "readme.txt", and the file is moved to the "additional files" block. For the "important.txt" file, they verify that the option is set to "overwrite." They then browse through the "additional files" block and deselect the "install" toggle button for all other unnecessary files. After the user is confident that everything is correct, they click on the "continue" button located toward the bottom of the window, are presented with a brief "Installing your script..." message, followed by an "Updating the script menus..." message, and, finally, are presented with the list of all installed scripts. Scripts that are installed locally using the installer will be presented with visual differences from scripts added using other means.

3. The user would like to install a script from a remote repository.

The user invokes the script manager from a menu, and is presented with a list of all installed scripts. They skip over all of this and locate and click on a "download" button towards the bottom of the window. Following this, a new screen is presented, the user selects the remote repository to use, and clicks on a "connect" button. The screen is updated with information regarding the connection status ("Connecting...", "Authenticating...", "Loading script lists...", etc.), and the user is then presented with a list of scripts similar in form and function to the list of locally installed scripts, but with additional/different options and information for browsing and presenting the individual scripts. As the user browses the scripts, visual cues and options will indicate whether the script in the repository is currently installed, is installed but has an update available, or is not installed at all. After finding and selecting the scripts they wish to download and install, the user clicks on the "install" button located toward the bottom of the screen, and is presented with a download wait screen. After the download completes, the user will be presented with the installation screen, and will follow similar processes to those given in use-case scenario 2 to identify and reconcile file conflicts and installation options. After the user is confident that everything is correct, they click on the "continue" button located toward the bottom of the window, are presented with a brief "Installing your script..." message, followed by an "Updating the script menus..." message, and, finally, are presented with the list of all installed scripts. Scripts that are installed from a repository will be presented with visual differences from scripts added using other means (including local installations - as in use-case 2) and will be listed with an update option when an update is available.

Project Schedule

Work can begin as soon as this application is accepted, and I am available full-time this summer. A base script is already under development [1], and the results are promising. However, it does not yet support all four features (full script management, script installation, script uninstallation, and a python CVS client). I estimate that it may take me the entire first month to add and refine the installation, uninstallation, and script tracking routines. The second month will be primarily spent on creating and incorporating a python CVS client, creating a GUI for browsing the CVS repository, adding support for CVS-installed scripts in the script tracking routine, and creating an update routine. The third month will be spent finalizing, publishing, and incorporating standards, refining the code, doing minor feature updates, organizing a CVS repository that utilizes the published standards, and recruiting authors to use the system. I will be available after the deadline for final bug fixes, integration, and, perhaps, additional development.

Bio

I am a 21 year old computer science student wrapping up my Bachelors degree from Excelsior College [3] and looking to pursue a graduate degree (in an unrelated field). I live in Abilene, KS (USA), and I have been working with Blender since the summer of 2000, focusing mainly on python scripting, modelling, and game development.

I have been programming for 6 years, with main experience in C/C++, Python, Java, and PHP. Projects have included 4 separate Blender-Python scripts (including a python script installer/manager [1]), a basic web content management system, the BPyC [4], and other course-related OpenGL projects such as display techniques (including interaction and animation), light baking, and image/pixel manipulation/filters.

I have a passion for serving and working with the Blender python community, and enjoy creating tools for users that enable them to use Blender more effectively.