While there has been a comment on the length of DJANGO_PKGNAMEPREFIX no one seems to have suggested shortening it.

In D7538#335854, @slw_zxy.spb.ru wrote:

I am looking at your comment for PR163461. 70-80% of wired memory don't have direct relation to system slowdown or hard reset (for example "Mem: 3107M Active, 10G Inact, 231G Wired, 42K Buf, 5802M Free" and no slowdown), thes symptomps are caused by very low free_memory.
In my patch I try to convert unused wired ARC memory to system-wide free memory early.

I have applied this patch to stable/11 r334820 and have been running without issue for 10 days.

While the blender code only tests a minimum python version, newer versions aren't officially supported. v2.79 was released 12/9 using python 3.5.3. Since that release the minimum has been increased to 3.6.2 for the next release, so there has only been a couple of months testing with py3.6. See the install_deps.sh used for 2.79 and the commit made a week later updateing this to 3.6.2 for the next release.

I would suggest patching the project (or requsesting the project devs make the change) so that it builds all available options and chooses which code path to use at runtime, this way the best option is always available with only one build.

In D12464#276665, @mat wrote:

In D12464#276045, @lwhsu wrote:

Just want to make sure, we can set FLAVORS in a individual port, for generating packages against the required python versions, right? For example, we may need py35-numpy for graphics/blender.

We can, yes. At the moment though, blender does not depend on numpy, so I could not have guessed that it would have been nice for it to have numpy.

Some further musings ....

devel/pyrex is similar to cython, it should be renamed, it has a misspelled PKGNAMEPREFIX= ${PYTHONPKGNAMEPREFIX} setting that prevents concurrent installs.

I haven't tested this and so far have only read this brief overview of how this will work, but I would go with bdrewery and have flavours as py27, py34, py35, py36...