I've been working on new portable archives for Windows
streamlink/windows-builds@master...portable

Please see the build logs and artifacts here:
https://github.com/streamlink/windows-installer/actions/runs/2468830991

Streamlink is currently lacking official non-installer builds for Windows, which makes packaging it a bit difficult for certain package managers, because those projects don't package python properly and they rely on standalone python environments for each application. Having official portable builds fixes that, even if it's a bit silly and redundant. And I guess some people on Windows don't want to use installers.

Please test the portable builds and give feedback.

As you can see, the changes are added to the streamlink/windows-installer repo, as it already contains lots of shared code for building, and the build config is exactly the same.

This means that the repo will need to get renamed once merged into master, which isn't a big deal, since GitHub will create redirections automatically when moving/renaming repos. The docs here will need to be updated either way. Any suggestions for the new repo name? streamlink/windows-builds?

Similar to the installers, the portable archives include the streamlink.exe and streamlinkw.exe executables, which are built the same way, via pynsist's nsist.commands module, using the distlib launcher executables.

The archives also bundle ffmpeg. And here's another decision that needs to be made. Since no config file gets written, --ffmpeg-ffmpeg will be unset. However, the portable builds of beardypig/streamlink-portable have a wrapper batch script, but that doesn't work well (argv issues because of %*).

--ffmpeg-ffmpeg could be added to the executables' header/preamble where it inserts hardcoded (dynamic) args to sys.argv at position 1. That would mean though that it would always override the value read from any config file, if one exists, and it could only be overridden via the command line, as the last argument set determines the final value. I've currently not included/hardcoded the --ffmpeg-ffmpeg argument. Any opinions on that? It's a portable build, so I guess it's up to the user to configure it properly.

Another thing I want to look into later is changing the packaging of the standard library, probably even for the installers. The custom python builds currently don't zip the standard library compared to the official embedded python builds. The zip file only contains compiled modules, but reading and extracting it in memory should always be slower (I guess, no idea if that's true), so I ignored that packaging step in the custom python builds. Extracting thousands of files is painfully slow on Windows/NTFS though, but since it's a one-time operation, having the standard library unpacked (with bytecode files) should be faster when running python. But as said, I don't know.
edit: switched to zipped std lib

Btw, the python packages that are not part of the standard library are not byte-compiled, because that would require running python -m compileall -q -f -s "$pkgdir" "$pkgdir" with the right python interpreter, and we're not building on Windows. The installers do that after extracting the files.

The installers also are using the LZMA compression, which yield significantly better results. For compatibility reasons though, I chose zip archives with deflate compression instead of 7zip with LZMA.