利用者:ReD Fox/Python script installer

Introduction

I am working on a python script installer for inclusion with Blender. This is my technical vision of the project, and will be revised based on feedback from the developers and the community.

Please post feedback here: http://blenderartists.org/forum/showthread.php?t=81748

Overall goals

• produce something that will benefit both the casual user, and the python script power-user
• Make installation and uninstallation as transparent to the user as possible
• Maintain file integrity
• Allow for better management and organization

Basic overview

• The script will allow users to add scripts, warning them of any conflicts or problems.
• The script will list installed scripts and allow users to organize and manage them.
• The script will enable users to safely remove scripts.

Technical documentation

Core functionality

This is what I am pressing for in the "basic" version of the installation script. It may be necessary to break it down further for development and release purposes, but I wouldn't consider it complete until all of the following are present.

For script installation

• Enable the user to install a single script that has been downloaded (an archive will be necessary for multiple files).
• Allow the user to select which script directory the script is installed in (Blender's default, the user defined directory, or maybe both).
• Scripts without a valid executable file (a .py file with an appropriate header) will not be installed. If a valid executable file is not found, and there is at least one file with the .py extension, the script will prompt the user to choose the executable file. Once one is chosen, a basic header will be added to allow the script to appear in Blender's menus.
• It will warn the user when a script they choose to install conflicts with existing files (if the files are identical, it is not considered a "conflict"). They will be given a list of the conflicting files, and for each file the option to 1) Overwrite (backups will be made), 2) Rename (in the case that the file is "executable," i.e. it contains a header), 3) Skip, or 4) Cancel (the installation will not proceed).
• If a file to be installed exists, is identical to the existing file, and is not an executable file, the file will merely become associated with the script via the installation ID. The result is that the same file can be associated with multiple scripts.
• If an executable file to be installed exists, is identical to the existing file, and the existing file is a part of another installation, the user will be asked if they want to 1) Replace the file (not recommended), 2) Replace the entire installation, or 3) Cancel the installation. If #2 is chosen, the install script will attempt to reconcile the differences between the scripts, requesting the user's intervention when necessary.
• For each executable file installed, the user will be allowed to choose which menu it is placed in (the script's header will be modified).
• Also, for each executable file installed, an ID tag will be added to the file (perhaps to the BPY header).
• For each file installed, the following information will be stored in the bpydata directory: 1) The script installation ID, 2) The file's md5 checksum, 3) The installation date, and 3) The backed-up file it replaced (if there was one).
• The installer will warn the user if the version of Blender running is different from the version(s) of Blender listed as compatible with the script. Initially, the policy will be as follows: 1) If the Blender version is newer than that listed in the script header, "soft" warn the user (will merely mention it before the script is installed, but will not require user intervention; or, the warning can be disabled), 2) if the Blender version is older, "hard" warn the user (require the user to explicitly decide to accept or ignore the warning).

For installed scripts (main interface)

• The option to install a new script will be displayed.
• All valid executable files (.py files with appropriate headers) will be listed.
• The scripts installed with the installer will be specifically noted/highlighted.
• Each listed script will display its name, version, menu group, installation date (if available), and location (blender's default dir or user defined dir). They can be ordered by name, date, menu group, or location, and can be browsed by 'All', 'Unregistered/Registered (installed)', or menu.
• Each script will give the user the option to change it's menu location (the installer will modify the file's header).
• The option to move/copy a script between locations (blender's default dir and user defined dir) will be displayed. It will consist of installing the script and all associated files to the other directory, and then (optionally) uninstalling the script from the original directory.
• The option to uninstall one or more scripts will be displayed for both registered (installed) scripts and executable files not explicitly installed with the installer.

For script uninstallation

• If the script selected for uninstallation is not registered (it was not installed with the installation script), it will simply be deleted on the user's confirmation.
• For uninstallation of registered scripts, each file to be removed will be hashed and compared with the stored hash (md5). If the file has changed, the user will be warned of this before the deletion.
• If a file to be uninstalled is associated with another script installation, the user will be notified with an option to 1) Delete the file anyway, 2) Leave the file alone, 3) Cancel the uninstallation.
• If a file to be uninstalled had replaced a file when it was installed, the user should be asked if the backup is to be restored.
• Before uninstallation, the user will be presented a list of the files to be removed, allowing them to deselect one or more files. If a user chooses to save a file, but continues with the uninstallation, the file's stored installation data will be deleted (just not the file).
• After an uninstallation process, an integrity check should be performed on the installation data and the installed files. Any file found that is not associated with a valid executable script will be displayed to the user with the option to 1) Save the file (but delete the installation data), or 2) Remove the file (and offer to restore any backups).

Additional notes

• File comparisons will probably be made using a hash or checksum such as md5. Executable scripts will be hashed after removing the header to allow for "identical" files possibly having modified headers.

Future/advanced functionality

This is some additional functionality I would like to eventually incorporate, but it requires quite a bit more thought and planning:

• It should have the capability to interface with an online or network repository (or several of them) to enable the user to download new scripts (note: when I mention "network repository," I am tentatively including in-house repositories on private networks, as well as the central online repository I've advocated in the past).
• For supported scripts in a repository, it should be able to notify the user when an installed script has an update.
• For supported scripts from a repository, the installer will notify the user if the script has not been signed as secure, and ask them if they still want to install it (a compromise to allow scripts that have not been officially reviewed/endorsed to exist in the repository).

Immediate questions/concerns

• Is it OK to modify script headers locally (on the user's machine) without authors' permissions?
• What's the best way to see if two files are identical in content? I know md5 would work.