Okay that makes sense. I guess I'll go that route then.
Thanks,
~ Isaac
On Tue, Oct 10, 2017 at 1:06 PM, Bastien Montagne
wrote:
> Yes, using threading in py scripts in Blender is perfectly valid - as long
> as you do not touch Blender data itself at all (nor try to
Yes, using threading in py scripts in Blender is perfectly valid - as
long as you do not touch Blender data itself at all (nor try to call
some operators from a thread, etc.). If you use your own code on your
own data, no problem with threading at all (i18n messages generation
script e.g. uses
It looks like you're using a threading executor to run each call to
requests. I thought that threading wasn't supported in blender[1], or does
that only apply to threading code that effects bpy.data?
What I'm doing currently is using asyncio.open_connection and building a
raw http request. But
Is aiohttp really necessary? I mean, we already bundle the Requests
library, so doing HTTP calls is already possible.
As far as asyncio goes, I've used it for the Blender Cloud add-on, and
it worked alright. I'm still not 100% convinced it's The Way To Go for
Blender, it has its pros and cons.
It applies to wheels as well, they're compressed archives of Python
source code, so aren't suitable for committing to git.
It's impractical to search the code and know what changes between versions.
We can bundle generally useful modules in SVN, as we do for requests and numpy.
On Tue, Oct 10,
I'm currently working on an addon that I would like to eventually get
included in Blender and was wondering if it's ok to use python wheels. The
guidelines say not to use binary files (
https://wiki.blender.org/index.php/Dev:Doc/Process/Addons#Never_Do) but I'm
wondering if that applies to wheels