[Soc-2017-dev] Weekly Report #09 - Package Manager

Ellwood Zwovic gandalf3 at blendermonkey.com
Sat Jul 29 08:47:12 CEST 2017


Here's my report for this week: 
https://wiki.blender.org/index.php/User:Gandalf3/GSoC_2017/Reports#Week_9

== Week 9 ==

What I did this week:

* Lots of code cleanup
* Added filtering based on install state and support level
* Added enabling/disabling
* Made a demo video:

https://youtu.be/b_iBVNmeBdM

I ran into an issue with multiprocessing on windows. It seems that 
windows doesn't have a nice system call like `fork` for *nix, so python 
has to create a new python interpreter from scratch. This is okay, 
except multiprocessing uses `sys.executable` as the thing to execute to 
get a new python interpreter. In blender's embedded python, 
`sys.executable` points to blender's executable. This means that 
starting a subprocess starts a new blender instance instead!
It seems the reason `sys.executable` points to blender is due to the 
[https://docs.python.org/3.6/c-api/init.html#c.Py_SetProgramName 
`Py_SetProgramName`] call made on line 244 of bpy_interface.c. If this 
is removed, sys.executable points to python, and it appears to work. 
Whether such an alteration to blender's python environment is acceptable 
is another matter (perhaps some other things expect `sys.executable` to 
point to blender?), will investigate further.

=== Plans for next week ===

Iron out various bugs which have been discovered (thanks to 
GiantCowFilms from stackexchange), then begin looking into progress 
display. Currently it seems the only method for doing this from python 
just changes the cursor, which I don't think is really optimal for the 
package manager (it doesn't indicate what the progress is for, can get 
in the user's way, etc). I'll investigate how the global progress "job" 
system might be exposed to python.


Ellwood



More information about the Soc-2017-dev mailing list