利用者:Gandalf3/GSoC 2017/Proposal
目次
Python Package Manager Proposal
Name
Ellwood Zwovic
Email / IRC / Social / Web
I can be reached through gandalf3@blendermonkey.com, and I’m usually in #blendercoders as gandalf3. I’m also gandalf3 on stackexchange and the bf-committers mailinglist.
Synopsis
This project will add a package manager to Blender’s current addon system with the goal of providing functionality similar to that found in Atom.
Benefits
Introducing a package manager will allow:
- Addons to be collected into decentralized, searchable repositories (e.g. official, contrib, blender market).
- Addons to be searched for, downloaded, and installed, all from within Blender.
- Installed addons to be automatically updated at the whim of the user.
- “Rolling release” style addon development.
In addition, future work could extend this project to add:
- New package types. For example, assets such as materials, nodegroups, texture collections, or even themes.
- A web interface for viewing repositories through a browser, making it easier to report bugs and request features in addons. (again, similar to Atom)
- Perhaps even a way for Blender to upgrade itself?
Deliverables
- Integrated UI allowing:
- Searching of packages
- Download and Installation of packages
- Update of installed packages
- Addition of package repositories
- Preliminary mockup of how this could look:
- Implementation of a repository server
- Documentation of UI and repository server setup
Project Details
Client
The client will be completely integrated, stable, compatible, unobtrusive, and asynchronous (non-blocking) — and leave the user in control over when package-related actions take place.
- Integrated
- From user POV, everything happens from within Blender (no need for user to use other software to install packages)
- Stable
- Gracefully handles exceptions, avoids removing old version of a package until the new version is downloaded successfully, etc.
- Performs checks for free space, write permissions
- Compatible
- Use existing addon installation methods; addons will be stored on disk just as they are currently.
- Be able to handle installation of addons created prior to the introduction of a package management system (be backwards compatible)
- Ensure it can be extended for new package types and try to gracefully handle unknown inputs which could be valid in the future (be forwards compatible)
- Unobtrusive
- Inform user of actions being taken/progress without modal popups or anything against Blender UX paradigms. (progress bar/reports in header should work well)
- Asynchronous
- Work in the background, allowing user to click “update all” and go back to modeling while addons are updated.
- User Control
- All actions are initiated by the user in order to avoid stealing precious CPU cycles or IO time during processing intensive tasks such as lighting or material creation — with the possible exception of an option to automatically refresh package lists and notify if updates are available.
The client will:
- Store complete package lists from all known repositories (allows quick searching)
- Provide a way for the user to add new repositories (in the form of a URL)
- Decide which version of a given addon to install, if multiple are available (possibly with input from user)
Server
The goal for the server side is to be as simple as possible, without compromising in performance or client usability.
A server will serve a repository which consists of:
- A directory containing the package files, and a JSON file which has:
- Information about the repository itself (name, maybe maintainer info, etc)
- A list of all packages in the repo, with information about each package, such as:
-
-
- Name
- Type (e.g. “addon”, “theme”)
- Version
- Compatible Blender version (for now keep it simple as it is in bl_info, but this could potentially support comparators like “>=2.75, <2.8” in the future)
- Author info, etc. (could possibly be pulled from bl_info)
- Size on disk
-
Package
A package is simply an archive (.tar.gz? I believe Blender uses gzip already for compressing .blends), which contains the files to be installed.
Package type handler
A “package type handler” handles tasks (such as installation, uninstallation) for a particular type of package. For instance, there would be one for addons, one for themes, etc. This should provide a flexible place for support for additional package types to be added in the future.
Some operations a handler would provide:
- Install package (i.e. copy files)
- Uninstall package (this could move the package to a temporary “holding” area to allow quick rollbacks. The need for this will depend on if repositories will support storing multiple versions of the same package)
- Pre-install check (ensure destination is writable, etc.)
Example installation process
How an installation might work:
- Ensure package list is up to date (do this efficiently to avoid redownloading same info; caching, conditional requests?)
- Check for available space, write permissions, etc. using the appropriate package type handler
- Download package tarball using name (or possibly a uuid or generated url) provided in the package list.
- Install archive contents with the method provided by the relevant package type handler.
Project Schedule
Before May 30: (In spring classes)
Week 1-2: (Finishing up spring classes)
Week 3: (Available full time)
Week 4-6:
Week 7: Implement search, add UI which allows for browsing, installing, and uninstalling packages.
Week 8-9: Implement multiple repo support, auto-updating of repositories.
Week 10: Start documentation
Week 11: Polish rough edges
Final week: Finish documentation
Second evaluation targets
For the second evaluation I intend to have a working, if simplistic, package manager. It should have the following functionality:
- An interface to browse packages contained in a packagelist which is downloaded from a configurable URL.
- Add URL preference - 30 minutes
- Add Packagelist downloading - 2 hours
- Add Packagelist browsing interface - 1 or 2 days
- The ability to install and uninstall packages from the list browsing interface
- Add uninstall function - 5 hours
- Add operator to expose uninstall function to interface - 3 hours
- The ability to search/filter packages
- 1 or 2 days
- User level documentation
- 1 day
Bio
I am a high school senior going to college full-time in the fall of 2017. In the meantime, I’m also studying computer science/software engineering at the University of Oregon, in the US. I enjoy taking part in community coding events; I’ve participated in local CoderDojos and hackathons. I’m also a moderator on blender.stackexchange.com, and have been an avid Blenderhead since 2.57. In fact, much of my python experience comes from writing games[0][1][2][3] in the BGE. Besides Blender and pretty much all aspects of 3D graphics, I also enjoy music and photography.
I want to do this project because I want to get more involved in Blender development, and because, as a user, I’ve been looking for an addon package manager for a long time (or at least a more organized place for addons, making it easier for developers to release them where artists can find them). I even thought of writing an addon to provide something similar before it popped up as a GSoC idea.
I’m an exclusive linux user (but I expect I’ll be able to test code on other platforms), and so have had exposure to a variety of package management implementations — and created packages for a few of them. I have some experience with HTTP (mostly with AJAX requests between JavaScript and PHP), and I’ve experimented with asyncio before.
That said, this will certainly be an educational experience for me. I will no doubt be learning new things as I go, but I intend to dedicate my summer entirely to Blender coding.
I’ve submitted one or two (very) small patches to Blender in the past, for instance: colorized menu shadows and additional theming control. So far nothing landed in master (except remove auto-disable renderborder), but I hope to change that soon! I’ve also contributed some documentation (and according to stackexchange, helped 4.6 million people with their blender questions).
