Closed myselfhimself closed 4 years ago
@douglaskastle has kindly worked for us on the abovementioned related issue.. It is time to catch-up.. Maybe after gmic-py's numpy branch release.
Envisioned version could be Python 3.5-3.7 (supported by Blender 2.8x ; adding 3.8 just in case). See this comment https://blender.stackexchange.com/a/117645/34778 and the 2.80's included Python shared libraries https://svn.blender.org/svnroot/bf-blender/tags/blender-2.80-release/lib/windows_vc14/python/lib/
unsure what your issue is here. I would just be trying to target the version of blender, the build of python just comes with it, unless you plan to build your own version of blender and maintain a different version of python?
If it is for running tests, then the python is the tool you use to run testing (so system python calling blender which is calling blender python), not what is being tested. Take what ever is the current default, which I believe is 3.7, and uprev it every year or so.
Hi @douglaskastle thanks, OK I had not found a page stating that python 3.7 is the target for any say 2.8x Blender version for now. I must stay the macos+linux python-compiled shared libraries sum up to 92MB right now... I will ditch one of the manylinuxes (2014 in favor of 2010) and Windows shared library will come maybe in a month.
What I want to test automatically for a versions matrix of (Blender 2.8[0-latest] x [Linux/macosx/Windows] x [32bit/64bit]):
Test 1. can be put in place anytime, and target just the Blender 2.80 x linux64 environment pair. It will be failing for now, but can help me develop the gmic-py module & presets import mechanisms until that test turns green. Then I can open it to more OSes & Blender versions.
I am deploying your example github actions right now on the current repository.. some news in 30 minutes I hope
This will be the way for caching Blender3d official archives between jobs and reduce the artificial downloads count effect we have on blender.org's statistics: https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows
A testing environment can now be more easily set up in the same form as this forked fake_addon: https://github.com/myselfhimself/blender-fake-addon/tree/master/examples/testing-fake-addon
Pytests now run using the myselfhimself/blender-addon-tester fork, but bypassing blender-addon-tester's zipping. Discussing this upstream now. G'mic Python module import is still broken for binary loading reasons, but commented for now.
Tests coverage are now a downloadable artifact within Github Actions jobs: https://github.com/myselfhimself/gmic-blender/runs/498517836?check_suite_focus=true
There is now one artifact per os and Blender version:
Caching of Blender release downloads does happen well per-os-per-version: 1st time: https://github.com/myselfhimself/gmic-blender/runs/503879688?check_suite_focus=true
2nd time: https://github.com/myselfhimself/gmic-blender/runs/503888841?check_suite_focus=true
Now working on blender 2.80,2.81a,2.82.. not 2.83 for ecological reasons (skipping runs) for now.
For me nothing more to do on this Issue, except than to switch to a proper pypi.org pip module URL when the blender-addon-tester
PR is merged or so.
Full compositing nodes test should take place when nodes are there.. A new issue should be opened for it..
The Blender Fake Addon project looks awesome and would allow to test an add-ons features against several versions of Blender x OSes maybe, on Travis. They are pytest-based which is nice.
Here is a related Issue created on their repository, regarding additional Github Actions support.
Looking forward to tackle this :)