2
$\begingroup$

I'm on an iMac using 10.14.3 (will be upgrading soon) and using Python 3.7.3. I'm using Blender 2.91.2 and the installed Python with Blender is 3.7.7. I have concerns about Blender installed Python (that I've asked about here) and am wondering if I'd be better off just using my system version of Python. I understand all I need to do to make that work is to rename the Python directory in my Blender folder.

My concern is what that changes. Is there anything special about the version of Python that comes with Blender? I know it's a newer version than on my system, but I would think, since they're both 3.7.x, that shouldn't be a big issue.

What kind of consequences will I have to deal with if I use the system install vs. the Blender install? Are there disadvantages to using the system install? My main reason for doing this is because I am adding modules to use in Blender scripting and I know that when I install PIP and other modules in the Blender Python, I'll have to redo those every time I install a new version of Blender.

I'd rather just use the system Python, since that involves less work when I upgrade Blender (just changing the Python directory in the Blender folder), but I want to know what consequences to expect before making that change.

$\endgroup$
2
  • $\begingroup$ Since you don't have to install Blender, but can easily run multiple version side by side, I'd suggest you do that for one and if at any point in time, there's a problem, revert - and also let us know. That said, I'd imagine that using Blender's built-in version is preferable, everything is tuned to that version. So if you don't have any parts of your scripts that depend on a certain version, I don't really see the advantage. $\endgroup$ Commented Mar 10, 2021 at 11:40
  • $\begingroup$ The frustration for me, in using the Blender Python, is that it means extra work every time I want to upgrade to the new version. It's not too hard to use the system Python and to rename the Python directory, but if I keep using Blender Python, with each upgrade, I have to change my bash script I use to run it (it sets PYTHONPATH to Blender's install), then re-install PIP from the command line (had trouble doing that from within Blender), then go through and use PIP to reinstall every module I've added. I think keeping my scripts version independent and using the system one is easiest. $\endgroup$
    – Tango
    Commented Mar 10, 2021 at 18:56

1 Answer 1

3
$\begingroup$

Opining on the pros of both.

Possibly walking a fine line re being closed as an opinion based question, more suitable for a forum

As I see it, the big "PRO" for the bundled python lies with the distributors and non python minded users of Blender. A Blender version is built against a certain version of python, and will only run when the x.y of the python x.y.z version (built against vs run against) match. Blender could distribute blender without a bundled python, and inform which version to install. Rather than doing this they have included a bare bones install of the required version.

As intimated in question, the big "PRO" of using a system based python is it is often a lot easier to install 3rd party modules using the OS's package manager, and to get help if and when there are issues.

Recall numpy being an example of this. Once upon a time the python bundled with blender came without numpy. As scripts and addons began to appear using numpy, so did questions of "cant install numpy to use with blender", "blender can't see my numpy"... Now numpy comes pre installed as a site package of the bundled python. The end user can now use the script / addon and be blissfully unaware of pip n PYTHON_PATH's and all that other "fun" stuff. Perhaps PIL may get in.

$\endgroup$
3
  • $\begingroup$ I get the point about it being opinion based, but since some issues are objectively definable and clear. I think what you state is clear and objective. "Blender Python does this..." and "System Python does this..." What helps is that you are basically telling me the difference between using one or the other and, for me, it lets me know that there don't seem to be hidden issues: It's about like I expected. It's not hard for me to keep a script version independent. I got used to that in the 80s with Assembler code that had to run on two similar processors. $\endgroup$
    – Tango
    Commented Mar 10, 2021 at 19:01
  • $\begingroup$ Those were the days. Did absolutely nothing for a semester of 68000 assembler for amigas (was at uni tavern instead) crammed the day before exam (with help from a bud) and it twigged. Did so well they made me a tutor the next semester. How much do I remember now? mov addr to NADA $\endgroup$
    – batFINGER
    Commented Mar 10, 2021 at 19:24
  • $\begingroup$ Started with a TRS80-Coco - it break down a lot. I went to Apple //e and loved it, and used Assembler. 6502 is a pain and 65C02 isn't much better. Only 8 bit numbers, no multiply command. Went from my //e to an Amiga 2000. Loved it but never did get to Assembler on it, but really wanted to work on the 68000. I'm mostly self-taught and did well with low level, so I often have a bit of trouble wrapping my head around some of the nice and useful higher level language concepts. In 6502, moving data meant loading it into the Accumulator, then storing it in the new place. Loop if more than one byte. $\endgroup$
    – Tango
    Commented Mar 10, 2021 at 19:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .