OBS Studio is outdated (Chocolatey version is 30.1.2 while latest version is 30.2.2)

[jeansagi]

Chocolatey OBS Studio is outdated at version 30.1.2.

It should be version 30.2.2.

J.

[jeansagi]

Any plans to maintain Obs Studio up to date?

[jeansagi]

Version 30.2.3 is now available...

Still my issue persist: Is there any plan to keep Obs Studio up to date?

I mean, this issue is almost 3 weeks old and there is no communication about it from the maintainer.

Do you need any help?

Kindly,

[AeliusSaionji]

Sorry. I'm currently on an extended stay away from home.

90% of the time when something goes wrong, it's because chocolatey's automated review process messed up. I simply do not bother to correct it for minor version bumps on actively developed projects, as it's an enormous and pointless time tax and chocolatey's autonomous system erroneously fails a lot. Usually the next update goes through just fine.

Missing two updates in a row does indicate something is wrong on my end. Perhaps obs have decided to rename their release files and my automated scripts no longer match. I'll try to find time to take a look soon.

[jeansagi]

Wow!

Nice to know.

I'm confident and eagerly waiting for the next release.

J.

[Zoullx]

When I pulled the repo and ran the update scripts for obs-studio and obs-studio.install I was getting a URL syntax error, so I had to add -NoCheckUrl to Update-Package. And then for obs-studio.install I was also getting an issue with an unknown file type from Get-RemoteFiles in au_BeforeUpdate so I just removed that whole function. Something to keep in mind though, is that I'm using the new chocolatey-au powershell module and not AU, so I had to remove the import at the beginning of the update scripts and I'm not sure if that difference is accounting for any of these issues. But once I did those things I was able to just run the update script like normal. Hopefully that helps in some way.

[jeansagi]

When I pulled the repo and ran the update scripts for obs-studio and obs-studio.install I was getting a URL syntax error, so I had to add -NoCheckUrl to Update-Package. And then for obs-studio.install I was also getting an issue with an unknown file type from Get-RemoteFiles in au_BeforeUpdate so I just removed that whole function. Something to keep in mind though, is that I'm using the new chocolatey-au powershell module and not AU, so I had to remove the import at the beginning of the update scripts and I'm not sure if that difference is accounting for any of these issues. But once I did those things I was able to just run the update script like normal. Hopefully that helps in some way.

Eagerly waiting for the update 😉.

[Zoullx]

I mean, I could make those changes and push them, but it raises questions for me as to why all of a sudden that would be happening and whether or not that's actually fixing the issue or just alleviating a symptom. I would want to figure out some way to answer those questions and make sure of everything before I pushed those changes.

[jeansagi]

Hope everything gets clarified.

This will help keep Obs up to date, for sure.

[AeliusSaionji]

The problem was what I expected: obs have changed how they package the releases. New filenames and new mimetypes. The update.ps1 intentionally looks for very specific matches because one of the other chocolatey problems is moderation will refuse to fix errors once published, and I've had a few instances of devs releasing packages with typos. In one instance a date typo killed the chocolatey package forever. It could be fixed, but moderation refuses to.

So... yeah. This is fixed. But also I strongly recommend not using chocolatey anymore fwiw.

[AeliusSaionji]

the fix if you're curious https://github.com/AeliusSaionji/chocopkgs/commit/3bc397d9a774a801190832d2dc99cb1def01dc7d

It might take a day to make it through the automated moderation. Let me know if it doesn't.

[Zoullx]

The problem was what I expected: obs have changed how they package the releases. New filenames and new mimetypes. The update.ps1 intentionally looks for very specific matches because one of the other chocolatey problems is moderation will refuse to fix errors once published, and I've had a few instances of devs releasing packages with typos. In one instance a date typo killed the chocolatey package forever. It could be fixed, but moderation refuses to.

So... yeah. This is fixed. But also I strongly recommend not using chocolatey anymore fwiw.

The reason why I use Chocolatey is because I have Ansible playbooks for all of my computers and use Chocolatey to install all of the apps onto those computers through the playbook. And as far as I'm aware winget still won't work with Ansible because of issues with session 0 or something; it's been a while since I've looked into using that. And I don't think scoop works very well with Ansible either, but again, it's been a while since I've looked. But I'm open to suggestions if you know of a package manager that has a lot of packages and works well with Ansible.

[AeliusSaionji]

You'll probably be stuck with chocolatey for a bit unless ansible works well with msys2 (it might, I don't use ansible).

My assessment of the alternatives:

• Winget is close to being ideal, but there are some minor annoyances such as ones that prevent winget from upgrading specific packages, or may cause winget to erroneously re-upgrade a package every time you run it.
• Scoop has the healthiest repository, but as best I can tell scoop packages go out of their way to use shims, and shims very consistently cause problems with explorer. A glaring fundamental flaw with the entire project, imo. But shims are usually fine for CLI tools and scoop thus is a decent way to add some CLI binaries to path, with notable exceptions like git: scoop's git appears to not support the windows ssh agent.
  • That being said, scoop also seems rather brittle, to the point that it breaks itself fairly regularly. And there are several built in commands dedicated to fixing scoop when it breaks. Not great.
• msys2 is solid and predictable and wonderful, but not all packages update in a timely manner, and engaging with the cygwin subsystem is definitely an exercise in creating new problems for yourself. Meanwhile the msys2 python (and other) native Windows environments are wonderful, but unfortunately many python projects and many dependencies thereof often fail when performing system checks, usually for no good reason. It's hard to justify installing all of msys2 for its package manager while ignoring the dev aspects.

I am personally experimenting with using a combination of scoop and winget, allowing UniGetUI to manage both.

It's not perfect, but setting aside some of my opinions about chocolatey's problems, it's pretty clear to me that chocolatey is and has always been a corporate product first. The community repository was created because there were no other decent solutions at the time, some decade and a half ago. That is no longer the case. Much of chocolatey's inelegance are not particularly a problem for the corporate userbase, so I don't see chocolatey suddenly deciding to improve along that axis- thus it won't be much of a competitor among the end user package managers.

It might be a bit early to switch for some, but the writing is on the wall imo.

[jeansagi]

Interesting opinions.

For myself chocolatey has always worked without much of a problem. I miss some features for the community (sorting by date although Business have it if I am not bad).

For me, the fundamental flaw on chocolatey, at least the community version, is its inability to purge older versions. Chocolatey package versions will invariably grow over time and the end user has nothing to do about it (maybe I don't know how). The only alternative I've found is to uninstall and manually search and remove for yourself all the debris chocolatey has left. A real hassle IMO.

Other than that, chocolatey is fine for me, 😉.

I try my best to have all the software I use as updated as possible, so I tend to open issues when packages are outdated obviously some packages are harder to support but here you, the maintainers, are the stars.

I will only consider using other package manager if the software I use cease to be available in chocolatey: but that has not been the case.

J.

[jeansagi]

Interesting opinions.

For myself chocolatey has always worked without much of a problem. I miss some features for the community (sorting by date although Business have it if I am not bad).

For me, the fundamental flaw on chocolatey, at least the community version, is its inability to purge older versions. Chocolatey package versions will invariably grow over time and the end user has nothing to do about it (maybe I don't know how). The only alternative I've found is to uninstall and manually search and remove for yourself all the debris chocolatey has left. A real hassle IMO.

Other than that, chocolatey is fine for me, 😉.

I try my best to have all the software I use as updated as possible, so I tend to open issues when packages are outdated obviously some packages are harder to support but here you, the maintainers, are the stars.

I will only consider using other package manager if the software I use cease to be available in chocolatey: but that has not been the case.

J.

BTW, Obs just upgraded flawlessly !!.

Thanks a lot!

J.