[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