Command line launchers based on distlib #169
See my comment here why this is important:
However, due to this change in pynsist, the Streamlink Windows installer is also affected by this (built via pynsist), and since it's a more popular way for Windows users to install Streamlink like this than using pip, this change now affects all of the Windows users without having a possible workaround.
The reason why this is a breaking change is how the python executables work on Windows. The built wrapper executables are always calling
The only way to suppress this behavior is executing
Hi @bastimeyer . Sorry for breaking your application, but I consider the
If streamlink-twitch-gui doesn't mind having logic to handle pip installs and Pynsist installs separately, there are a number of possible approaches you could take.
The new exes do also include a plain-text shebang, if STG wants to find and read that. It has to be fairly straightforward to do, because the exes themselves find it with code written in C. However, that mechanism might change again in the future, so be prepared to have to update it if you go down that route.
Thanks for the hint! Sounds like the commands would use the
Hm, that's very unfortunate. With this removal you're basically asking every application that's packaged with pynsist to include their own stuff in case other GUI applications depend on it, and those have to implement this custom stuff.
The reason why this change is so bad for my application is that prior to it, you could simply run
So wouldn't it make sense creating two binaries for each command in pynsist, similar to
I'm not exactly sure of the implementation details, but they either use that or do something that has the same effect.
I guess it wouldn't hurt for commands to have a
So I've tested the executables created with the
All that because of the removal of regular python entry script text files.
I'm sorry, but I have no idea where to add this. I also don't have the time for tinkering with that either.
It looks like they always wait for the child process and then exit with its exit code:
WaitForSingleObject(pi.hProcess, INFINITE); ok = GetExitCodeProcess(pi.hProcess, &rc);
But the only way to be sure is to test. If you create a wheel with
The definition of the command sections in the config file is here:
This code copies the launcher exe into the build directory where it will be bundled into the installer:
And finally this small file runs at install time to assemble the exes with the shebang. I'm hoping a future version of the launchers will support a relative path to Python, so we can do the assembly at build time:
I'm not saying this because you have to make a PR yourself. I might get round to it. But I want to make it clear that:
Ok, tested it and it works. That's fantastic and should solve all of my issues.
I will see if I can assemble a pull request in the next couple of days when I get the time. Thanks for your help so far and sorry for spamming this thread.