Python feels like a second class citizen in the Vapoursynth ecosystem

[Oliver1990]

To preface this, I come from a Python and JavaScript background with a few years of experience there. Finding out about Vapoursynth and the fact that it used Python as its scripting language was enough for me to pick it up and not bother with Avisynth's DSL.

I think Vapoursynth is already the best option for what it does but I also think it can improve UX in a variety of ways. The feedback below is essentially what I think Vapoursynth of the coming years should improve upon. Note that this is pretty much focused entirely on the python side of things, because that's where I think VS is lacking.

I think Python and Vapoursynth currently create friction for each other.

• Supporting a single Python version at a time - The chance that the user has the exact Python 3.major is low, and newbies especially suck at managing multiple Python versions. So their option is to uninstall whatever they had to match whatever VapourSynth wants. If your VS scripts depend on any other dependency, they must also support the same Python version. But I also understand supporting 5 Python versions (following core Python) might be a bit too much, so my suggestion here would be to adopt SPEC-0, used by the scientific Python community (NumPy, SciPy, etc.), which recommends only supporting the last 3 Python major versions.
  
• Lack of pre-compiled wheels for major operating systems - Currently, one cannot do `pip install vapoursynth` and expect it to work on Windows, MacOS, and Linux. Needing a global install for VapourSynth scripts directly goes against recommended Python practices and makes scripts far more brittle. Having a definitive and cross-platform way to install VapourSynth via PyPI would make getting started with VapourSynth a breeze. This isn't uncharted territory; lots of native libraries already publish pre-compiled wheels. Once again, I'll refer to what scientific Python libraries do as an excellent read on this topic.
  
• Plugin distribution - Like VapourSynth, plugins must be installed globally with VapourSynth and add yet another external factor that every VS script implicitly depends on without declaring it. Installing them is error-prone at worst and a janky experience at best. I think in an ideal future where VapourSynth has shifted to PyPI and looks into Python environments for discovering plugins by default, it would open up the ability to publish plugins on PyPI, making them a `pip install` away. A good reference for this would probably be pytest and its massive plugin ecosystem built on top of pluggy.
  
• Lack of reproducibility - Because of all the points mentioned above, getting reproducible environments for VS scripts is practically impossible (short of building a Docker container). This makes VS scripts extremely brittle to time and changes. These scripts implicitly depend on several external (undeclared) factors that they are almost guaranteed to break if left untouched after a while and the environment changes (which it will).

Just to add to this, I'm definitely aware of projects like`vsrepo` and `vapoursynth-portable`. They're helpful, but from my experience, they don't quite get to the heart of the issues I've been talking about with Python integration.

This issue has been cross-posted to and is now being discussed at vapoursynth/vapoursynth#1111.

[squillful]

Agreed strongly with all of this; I've been thinking the same thing. You should consider opening an issue in the vapoursynth repo. I'm sure they would welcome the contributions too (would be interested in potentially contributing to something like this if I could find the time)