PR: Windows Installer script #13269
PR: Windows Installer script #13269
Conversation
|
That is pretty cool @dalthviz. Maybe it would be good (later on) to a check in here https://github.com/spyder-ide/spyder/blob/master/spyder/tests/test_dependencies_in_sync.py so that the config file remains in sync as well. |
|
Note: Mu script to create the config file dynamically and run the build process: https://github.com/mu-editor/mu/blob/master/win_installer.py |
|
After running Spyder for a while (overnight, just under 24 hours) I Alt-Tabbed to it to notice a bunch of kernel died messages displayed in the Spyder error dialog. It wasn't sleeping that did it since it worked just fine a few hours ago, well after I'd hibernated my machine overnight. However, there appeared to be no ill effects; the two kernels I had running (in the builtin env, and in my Anaconda 3.6 env) still worked normally. I also had a dead kernel still open with the error message as reported above in @dalthviz 's OP due to using a Python version != the Spyder runtime version, though it wasn't the active one...perhaps that had something to do with it. |
|
Note: Check installer creation using conda constructor |
|
Note: To use constructor. For menu generation (?) |
|
Note: Check pyinstaller option |
|
Update:
|
You could potentially work around this by launching the LSP processes using |
Ok, this means that we can't use Constructor for the installer.
This seems like a quite terrible limitation. |
That's not possible anymore because we switched to use QProcess instead of subprocess in 4.1.4
I'm strongly -1 on this one because that would deviate us from the way kernels are handled by the vast majority of (if not all) Jupyter projects. In other words, that would be a terrible maintenance burden because, on top of maintaining of our own kernel, we'd need to maintain our own architecture as well.
I also disagree with this because the installer wouldn't be usable for scientific computing without another Python installation. So it couldn't be deployed at large in schools or enterprise environments. |
|
Note: Try with cx_freeze 6.x |
|
Note: Try with py2exe |
|
Note: Seems like the embedded version of Python 3.7.9 was released on August 17 so checking again I was able to create an installer with Python 3.7.9 (although seems like the restriction of the kernel needing to also use the same Python version persists) Edit: Using pynsist |
|
Note: Check Briefcase Edit: Napari PR where they use Briefcase to create the installers (also show a way to setup Github Actions to attach elements to a release and trigger the build) - napari/napari#1289 |
|
@ccordoba12 checking
Checking a little bit seems like this issue explains some alternatives to tackle the error: beeware/briefcase#381 In terms of the installation something to notice is that the installation is always done in The branch with the changes to build an installer is here: https://github.com/dalthviz/spyder/tree/briefcase_installer Also, just in case some branches where I tested other packages: |
|
Thanks @dalthviz for the update and your hard work on this! What's your final conclusion? In other words, what installer method do you think we should use on Windows? |
|
@ccordoba12 I think for now using Edit: Although probably another approach for the way to handle the |
|
Note: Example GH Action to add assets to the release - https://github.com/napari/napari/pull/1289/files#diff-133717b789402c2a8618aa4f47d79ff2 |
dalthviz
force-pushed
the
installer
branch
2 times, most recently
from
1e40f0d to
79095f9
Compare
|
Note: The creation installer workflow uploads an artifact to the workflow execution. As an example: https://github.com/spyder-ide/spyder/suites/1298474294/artifacts/20340090 From the GitHub UI it can be found in the workflow: |
That's pretty cool @dalthviz! Does that mean a new installer will be created per PR too? |
|
Just in case, as a note: The workflow can be setup to generate the installer per PR or other types of events (for example tag event or release) However, if we end up adding a step that uses the GitHub API (for example uploading the generated artifact to the respective GitHub release) the workflow will only run once per event (for example only when the PR was first opened) |
dalthviz
changed the title
|
@ccordoba12 I think this is ready for review 👍 |
There was a problem hiding this comment.
Thanks a lot @dalthviz for your hard work on this! It is awesome!
Co-authored-by: Carlos Cordoba <[email protected]>
… of NOTICE change
There was a problem hiding this comment.
Thanks a lot @dalthviz! Another fantastic addition for 4.2!
Description of Changes
Add a config file to use
pynsistto create Windows installerSteps to build:
Create an env with python 3.6.8 and
pynsist(you should use only pip to install packages in this env):Install the packages listed in the
installer.cfgfile in the env:autopep8diff_match_patchintervaltreenumpydocpandocfilterspathtoolspyrsistentropewatchdogwraptThe rest of packages listed are accessible via the
pywin32wheel but needed here to prevent aNoModuleFoundErrorwhile starting the console kernel using the default interpreter (the one embedded in the installer):win32apiwin32securityntsecurityconOver the root of the repo run
pynsist installer.cfgpynsist env packages and versions
Install preview
Uninstall preview
Issue(s) Resolved
Fixes #13145
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.
I certify the above statement is true and correct: dalthviz