sbruder
commented
1 year ago Thanks for opening this, I wanted to say something about this, but never came around to actually do it. First, I’m sorry for not being able to maintain this and leaving this in the state it is in currently. I added many plugins when I used vapoursynth quite a bit but now I sadly don’t have much time for vapoursynth and maintaining this overlay.
As I introduced quite a few of the packages in this overlay, it’s my “responsibility” (at least I feel like it is, because I wrote that code in the first place) to take care of them, so if you have any questions about a specific thing, don’t hesitate to reach out to me. However, as you can probably see from my low activity (not only) in this project, I don’t know if I’ll be able to help you quickly (because most things in here are quite complex, so I have to think about them for some time).
I am definitely interested in making sure that vapoursynth in Nix has good infrastructure because its sheer amount of plugins with different variants makes it a prime candidate for packaging with Nix.
I’ll quickly address your points, though that is by no means an exhaustive discussion, just what I think of it right now:
The biggest problem I noticed while trying to use the overlay is that alot of stuff is outdated or missing and probably needs active maintaining to not break when you want to update a single component (especially for stuff from Irrational-Encoding-Wizardry)
In general that is what we want, though many plugin updates have breaking changes, so a way to use older plugin versions would be great (though probably not that easy without evaluating multiple versions of the overlay).
There is seems to be no proper care for versioning in the vapoursynth space i.e alot of packages just have fixes in master but there is no release, but stuff depends on them. : Whats the best course of action ignore release and always take a unstable commit?
I think addressing this requires cooperation from upstream (maybe some aren’t aware that not versioning causes problems?). Until upstream versions packages, the only thing we can do (AFAIK) is using the latest commit.
There should also be a proper checkPhase for binary plugins that checks if the plugin shows up. : I have alread programmed this but I dont't like the implementation
That’s right, ideally this could be done as a hook (like how pythonImportsCheck works).
There is also the chance for some random breakage due to nixos updating (for example vapoursynth updates, I had alot of trouble with ncnn and glslang) : Maybe some hydra thing sbruder mentioned, or just someone that checks every few week if everything still builds on nixos-unstable
Yes, Hydra would be nice for ensuring compatibility with the latest nixpkgs version, though I don’t know that much about hydra and if the “legacy” (non-flakes) method will still be supported (or how to implement that with flakes, which normally pin the inputs).
There is also alot of redundant copy paste in the .nix package files, should these be refactored out or would that lead to even more problems (python checkPhase, meson install dir, requirements.txt vapoursynth removal)
I also though about this but because of the different ways the plugins can be built, I couldn’t figure out how to abstract this (some are plain python, some are python modules with native code, some are just native code (C/C++), some are written in Rust, …).
And the whole python testPhase binaryPlugin/pythonPlugin seperation problem.
That’s a very complex problem indeed. Every possible way I could think of (as it is right now, multiple outputs, multiple packages, differentiation in the wrapper) has some downsides, especially because python plugins can depend on native plugins.
: In my opinion it would be best to transition to a model where all vapoursynth binaryPlugins are collected in some env variable (like PATH or PYTHONPATH) instead of having to build a extra withPlugins derivation with python and vapoursynth stuff combined.
I think the withPlugins mechanism is a good way in principle (many packages in nixpkgs are doing it that way), though a separation is probably necessary. But if there is a way to avoid the problems by not using the withPlugins mechanism, I won’t be opposed to it.
I would also propose some external "integration?" test than just checks if filters run and dont't throw errors. We currently can't catch missing dependencies if their just used in a function or from binary plugin
That could be done by adding a derivation that runs the tests to passthru.tests (the testing mechanism could be abstracted).
I have wrote quite a few packages and utilities now, would anyone be interested in me cleaning my stuff up and trying to upstream them here? (My plan is to be on parity with vapoursynth-portage and AUR)
As already said, I probably won’t have the time to thoroughly review them, though it definitely would be great to have an alternative vapoursynth distribution to the de facto standard (AUR).
There were also a few things that I wasn't able to package that whould be nice to have like (https://github.com/Irrational-Encoding-Wizardry/yuuno)
I also tried packaging that once, but gave up because I didn’t fully understand jupyter (and to an extent python) infrastructure in nixpkgs.
sshiroi
tadeokondrak
compguy284
aidalgol
Since I saw activity on this repo again I though I should write about a few things that in my are relevant for discussing.
I will continue working on these problems myself, but I think it would be best if someone with more nix/vapoursynth knowledge could comment.