obsproject
Add RFC: Add install python scripting support to installer
Description
Add the option to install python scripting support to the windows installer
Motivation and Context
Ease the path for people using python scripts in OBS
Read RFC
Most regular users probably have no idea what Python is and won't check that box when installing OBS so by the time they find some Python plugin they'd like to use most probably would still not have it installed. At that point they'd either have to use install python by hand or use the OBS installer to reinstall with it checked that time, makes it a bit easier but not much. This also wouldn't help anyone that already has OBS installed and just uses the updater for new versions which is probably a large portion of users. Also doesn't help anyone using the installer-less OBS zips.
Why not bundle Python with OBS itself. Python.org offers fully featured but pretty small bundles of python for embedding in applications. They are like 5MB zipped and 10 uncompressed which doesn't seem that bad to include by default and just set that as the default python path in OBS. Anyone that wants to use their own install can still point it to their custom one themselves.
Alternatively if bundling is not acceptable it might be nicer to have an Install Python button in the Python script settings in OBS that downloads the .msi and installs it and sets the path. Would cover every user on Windows regardless of how they installed OBS or how they're running it or if they're new or existing.
Edit: Doesn't even have to be the full .msi install which might need admin rights to install and could be annoying because of it. Could just download the embeddable python zip version and unpack that in a folder in the OBS appdata folder and set that as python for OBS, to avoid needing admin rights and being less invasive on the users system with installing something.
I feel like this RFC is lacking in some details. I wish more time had been put into technical considerations and drawbacks.
I don't like the idea of pre-writing a global.ini file with the installed location of Python, because that short-circuits OBS's first-time launch procedure.
What considerations are there for non-Windows platforms? Though the RFC doesn't say it, explicitly, this seems like a Windows-exclusive proposal.
How do we keep this updated in our build scripts with minimal effort?
I seems you made a PR for this before the RFC was merged. We'd usually prefer to have the RFC merged before making a direct obs-studio PR.
I am concerned about adding binary/executable downloads being added to the installer. Those downloads/data need to be checked/signed in some way in order to minimize the chance of some sort of MITM or something. I understand the desire to solve Python as a support issue, and I am grateful for that, but if we add downloads to the installer we will need to make sure that we have everything checked there. It's possible that the NSIS plugin has support for signing of some sort, but if not then that'll be a problem.
Additionally I think there's also some problem anti-virus tools when it comes to installers. I remember that things like this will trigger anti-virus and get the installer flagged, which is annoying to deal with.
Why not bundle Python with OBS itself.
I implemented Python in a specific way to allow users the full power of Python, and to allow them to use things like PIP/etc so they can do more advanced things. It wasn't meant to be a basic scripting language for users, that was meant to be left to Lua because we prefer people to use Lua when possible. Python was implemented in a non-bundled way so that users can install Python on their system and have access to any package they have installed with it. Bundling Python would make things like that more difficult.
Making Python easier to install comes down to the Python version issue more than anything, which was an issue with SWIG and OBS itself. I think we solved it for the most part in 27 but it still needs testing. I know that configuring it sucks, It's a UX balance however. Sometimes I feel like it's not too big of a deal to make super advanced features like Python require a little bit of configuration to use. UX issues are a top priority, but I feel like users installing Python is the least of my worries in terms of UX and much lower priority than other UX issues.
Besides, I don't really feel comfortable with the script system in general, despite the fact that I wrote it. It still needs a lot more work to make me happy than just the "how do you install Python" issue. It needs RAII work to make it more safe/stable.
This RFC seems very barebone compared to other RFCs, lacking almost all critical information necessary to actually do anything with this. It doesn't define what the correct Python MSI file is, or how we would detect if the correct Python version is already installed (removing an unnecessary step for some users), etc.
The drawbacks are also very barebone and lacking actual technical information. From my perspective the drawbacks are this:
- Users which do not know about or use Python may incorrectly check the box, adding Disk and Network usage where none is actually needed.
- Detection of the correct Python version is necessary in order to automatically skip the download and install step.
- This doesn't help people using the updater.
Python was implemented in a non-bundled way so that users can install Python on their system and have access to any package they have installed with it. Bundling Python would make things like that more difficult.
I don't see why it would make it more difficult? Just because you bundle one and set that version by default doesn't mean you need to take the option of using a different local Python away? All I'm suggesting is sticking the 6MB Python embeddable version (which still has the full stdlib) in the OBS folder and just setting that as the default path for Python in OBS. Anyone that wants to use their own Python with their own PIP and local packages can still do so just as easily as before. You just have a guaranteed baseline of Python for all users.
Or if you don't wanna include it by default have a button in the python script settings that downloads said 6MB Python embeddable zip and unpacks it in the obs data folder and just sets that as the path.
It wasn't meant to be a basic scripting language for users, that was meant to be left to Lua because we prefer people to use Lua when possible.
Lua is very nice as a scripting language and perfect if you just wanna do OBS internal things within your script but the way libraries work in it they almost all require platform specific libs so the second you wanna do any basic higher level thing like just http/websockets/whatever you're right back to having to ship platform specific dll/so's and all the trouble that comes with that.
Currently there just seems to be no real good option for writing higher level OBS scripts/plugins for anything beyond the limitations of Lua. Python doesn't have that issue anywhere near as much as it has a nice std lib and most 3rd party libs are still mostly pure Python (with platform specific wheels being optional).
Using Python for OBS scripts seems like a pretty bad option as a dev right now almost purely because of users having to install it which is a huge hurdle for many (really doesn't help either that the Python Windows installers have lots of variety on where they actually install it depending on what Windows version, is user admin or not, some other env dependent things and whatever options the users selected). Even if you make clear enough instructions or just make your own custom installer for your plugin that sets it all up then that would still break down the second a user wanted to run two different Python scripts from two different devs both doing different things to get Python actually working on the users machine.
So with Python being relegated to "personal" plugins but not ones targeted at the general user base you're basically stuck with either having to make a native plugin or dealing with the platform issues with Lua. Just seems kinda unfortunate as Python seems perfect for all those little higher level plugin needs otherwise.
PS: While this is very Windows centric on Linux you have package managers so not much of an issue there and similarly on Mac package managers seem reasonably common and the official Python installer there is also way more standardized than the Windows one but embedded Python on Mac would also still be doable reasonably easy otherwise.
PS: While this is very Windows centric on Linux you have package managers so not much of an issue there and similarly on Mac package managers seem reasonably common and the official Python installer there is also way more standardized than the Windows one but embedded Python on Mac would also still be doable reasonably easy otherwise.
FWIW OBS right now "memorises" the name of the python library when obspython is built, so a release built with Python 3.8 present will only load libpython3.8, which is an issue if you have Python installed via Homebrew (current version 3.9.2) and requires symlinking/faking the presence of the 3.8 version.
So at least on macOS I'd prefer "forcing" use of the system-supplied Python3 that macOS ships with and not shipping anything ourselves.
which is an issue if you have Python installed via Homebrew (current version 3.9.2)
Homebrew finally has separate bottles (casks? taps?) for 3.7, 3.8 and 3.9 now to let you install any/all of them just via official brew I'm pretty sure so that shouldn't be an issue anymore. And macports always had that already.
For some reason I thought Apple was gonna remove python from future MacOS versions completely at some point but seems that announcement was mainly for python2. Both 10.15 and 11.0 appear to come with 3.8 which would cover most Mac users yeah, nice.
@willlllllio OBS will still not be able to pick up any other version but the one it was built with, as that library name is hardcoded at compile time (PYTHON_LIB define in https://github.com/obsproject/obs-studio/blob/master/deps/obs-scripting/obs-scripting-config.h.in).
As the version supplied by Apple should more or less be stable for an entire OS cycle, it would be easier if OBS is built with that version in mind, with the optional feature of specifying a path yourself (because you're either on a non-current version of macOS or use a more recent version installed via Homebrew).
@PatTheMav Ohh yeah I get that it will only load the same version it was compiled against and compiling official OBS on Mac against 3.8 and using the preinstalled one makes the most sense then, I was just saying that the annoying thing where homebrew users were screwed if there was a newer python version out in homebrew than the one OBS was built with isn't any issue anymore now since you can finally easily install older versions via brew too for anyone that wants that. I thought that's why you were mentioning that.
We no longer require a very specific version of Python, so this should be much easier for end users. Honestly, the best thing we could do is just improve automatic detection of Python installed on the system already, but that's far simpler than the scope of this RFC, which we feel is no longer necessary now that we support more versions of Python and it's a lot easier to get set up.
Moving to Final Comment Period, with Disposition Close.
