Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Build additional "streamlinkw" launcher on Windows #2326
This adds an additional
Motivation of this PR and why this change is needed
A couple of months ago, both
That's why I'm submitting this pull request, which adds
I've already submitted a PR to pynist (takluyver/pynsist#179) a couple of days ago which adds a new
Regarding the Streamlink python wheel, an additional
Issues / Open questions
referenced this pull request
Feb 25, 2019
@@ Coverage Diff @@ ## master #2326 +/- ## ======================================= Coverage 52.59% 52.59% ======================================= Files 237 237 Lines 14797 14797 ======================================= Hits 7783 7783 Misses 7014 7014
@@ Coverage Diff @@ ## master #2326 +/- ## ========================================== - Coverage 52.59% 51.37% -1.22% ========================================== Files 237 237 Lines 14797 14469 -328 ========================================== - Hits 7783 7434 -349 - Misses 7014 7035 +21
What it actually does? See takluyver/pynsist#179
Again, and I don't want to repeat myself over and over
No, because that would break situations where a terminal window is desired/needed, like for example when launching
If python on Windows wouldn't have this stupid distinction between python/pythonw, this all wouldn't be necessary.
I've been trying to solve this mess for the past two weeks now and adding an additional "GUI" launcher is the only way to properly and sensibly fix this. Otherwise, every non-CLI application using Streamlink that doesn't want a terminal window from being shown would have to parse the binary launcher executable for the included shebang, so that the path to the python executable can be found and replaced with pythonw. This is nonsense.
There is no harm in adding an additional executable to the Windows installer. The wheel however is a bit different, because it also affects Linux and macOS. So if a different flavor can't be built and published explicitly for Windows, we can remove the
Yeah, I got all that from the previous issues, I was just wondering if a regular
If we build separate wheels for each platform we could probably include it just for Windows, but as we are building universal wheels I don't think we can do it as-is. Maybe @back-to knows more.
I'm fine with the name, but if you want another suggestion
We just need to build an additional Windows specific wheel. That will be selected first on Windows, so there's no need to change the current config.
Would it make sense copying setup.py to a temporary location, modifying it and renaming the output wheel name? Or is there an easier/better way for building platform specific wheels from one location?
That's probably better :)
Looks like we need to build Windows specific wheels for
Regarding the actual build procedure, would it make sense adding a diff/patch file for setup.py that gets applied after building the non-platform-specific wheel and then building the specific ones? Before I update this pull request, I'd like to get some feedback first whether this is the right path to take here.
I'm not too fussed having the
Update: I checked and they behave identically on linux and macOS. I don't know of debian/arch/etc would have an issue with the extra binary though...
Let's not add this to Linux and macOS. Remember that this will add a duplicate entry script to the user's PATH and will make tab-completion a bit annoying.
Regarding my patch file approach, this unfortunately won't work because of versioneer. The resulted version string will have a
Feb 28, 2019
@beardypig Could you please review these changes when you get the time? Since you're the one who wrote the sdistsign script, I would like to have it reviewed by you.
I could split the PR into two, one for the installer and one for the wheels if that's better or if you don't have the time right now. The installer changes should be a no-brainer and could get merged immediately.
I would really like to have this merged and a new release published, because the Twitch GUI is in an awkward situation on Windows since Streamlink's 1.0.0 release.