Windows setup on Local Environment #5321
Conversation
|
This should not include any changes to schema.rb. It probably also should not include changes to the Gemfile — if those are necessary, perhaps they can be documented in the setup instrutions? — although if we can get the build passing with the platform-specific entries, it might be fine. |
|
Hi @ragesoss , can I add the db schema to the gitignore?. For the Gemfile I'm wondering whether I can add it in the setup instructions for Windows users to comment out stackprof in their local and not push that change upstream? In the meantime I can check the ones that will pass the check. |
|
@sharon-odhiambo no, you can't add schema.rb to the gitignore... it should just only change when there are new migrations, usually. the schema.rb file is automatically generated whenever any migrations are run, but it reflects details that are specific to the system it is run on (such as database settings that are not configured by the app itself), so running the existing migrations on different systems results in minor differences in the schema.rb files. We usually just exclude these from commits; you can use The instruction changes you suggest for stackprof sound reasonable. |
|
This should include no changes to schema.rb. I'm okay with the change to the Gemfile itself (relaxing the Ruby verison), but I'd also prefer not to introduce any changes to Gemfile.lock here, since I'm not entirely sure how it would interact with production. |
|
Hi @ragesoss . Sure lemme incorporate this. I will update the Windows specific changes to the Gemfile in the detailed instructions. |
|
Hi @ragesoss . Incorporated the feedback. |
setup/deb-setup.sh
Outdated
| @@ -117,6 +117,8 @@ else | |||
| fi | |||
|
|
|||
| printf '[*] Installing Gems... \n' | |||
| output_line "sudo apt install libmysqlclient-dev" && print_success "${CLEAR_LINE}[+] Gems installed\n" | |||
| output_line "gem install mysql2" && print_success "${CLEAR_LINE}[+] Gems installed\n" | |||
There was a problem hiding this comment.
This shouldn't be necessary to do separately, as mysql2 gem is part of the bundle specified in the Gemfile.
There was a problem hiding this comment.
Hi @ragesoss, thank you for the feedback. Mysql2 gem installation was a bit problematic with the Gemfile in debian when mysqlclient is not installed so including it was helpful. So should I remove both line 120 and 121 or just 121?
setup.py
Outdated
| @@ -36,7 +36,10 @@ def osx_setup(): | |||
| subprocess.run("sudo chmod 775 setup/macOS-setup.sh && setup/macOS-setup.sh", | |||
| shell=True, check=True) | |||
|
|
|||
| if platform.platform().lower().find('ubuntu') != -1 \ | |||
| if "microsoft" in platform.uname().release.lower(): | |||
There was a problem hiding this comment.
What if the computer is running Windows but does not have WSL (either because it hasn't been installed or enabled, or because it's running an older version of Windows that does not support WSL)? I would guess that it might still have microsoft in the platform name that Python sees.
There was a problem hiding this comment.
Hi @ragesoss, let me check this. Just a clarification, I'm I supposed to confirm that it doesn't run the debian script when the machine has only Python without WSL?
There was a problem hiding this comment.
I'm not sure. It should either work no matter what, or it should fail gracefully by detecting that the system isn't compatible with the scripts and exiting with an appropriate message.
There was a problem hiding this comment.
Okay then. In that case can I check if WSL is enabled or installed and run the debian script, else I can run the windows script? I included in the documentation that WSL is the recommended option but in case the version doesn't support WSL they can fallback to Windows script. Would this be okay?
There was a problem hiding this comment.
If you know that the debian script works on WSL, then that makes sense.
There was a problem hiding this comment.
Yes it does. Okay lemme go ahead and do that. Thank you.
|
Hi @ragesoss , kindly ,let me know if this is okay now. |
|
Thanks! I'll test it on a clean Windows device when I get a chance to. |
|
Okay. Thank you. |
|
Hi @ragesoss , I have a further question on this. Before I automated this script and fixed the bug on Windows script, it would not run at all. However at the moment, If you run the setup script from Ubuntu terminal for WSL users, it runs the debian script. If you run it from windows bash terminal, it runs the Windows script even if the version has WSL. Is that the desired behavior? |
|
Hi @ragesoss . Another one again 😆 . Did you manage to test this? |
|
I reset my Windows laptop in preparation, but haven't tested it yet. |
|
Okay, I'm finally working on this... I started from the WSL setup doc, https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/docs/ubuntu_wsl_setup.md — and I'm realizing that I don't know exactly how I ought to integrate this with your script updates... the script is not designed to install Ruby, and while the WSL setup doc says to use RVM from within an ubuntu terminal, in the general setup doc is still says to use RubyInstaller. Which path did you take? I think the RVM method from the current WSL setup doc will be the more reliable one, but I'm not certain. |
|
So for WSL option I think I used RVM, but for the Windows users who can't completely use WSL I used RubyInstaller. Maybe I should update that in the documentation. |
|
Cool. I think we should switch to recommending WSL and RVM as the default method, as RubyInstaller is never going to be as reliable in terms of version availability, and WSL seems pretty solid as a way of running a dev environment now. |
|
Yeah sure, WSLis quite effective at the moment. Updated the documentation. |
|
Okay! I've install Ruby on WSL on my test machine, downloaded the git repo, checked out this branch, and attempted to run |
|
I ran the platform command from the setup script (from within the Ubuntu terminal, as I think will be the right way to do it for WSL) and it gives "Linux-5.10.16.3-microsoft-standard-WSL2-x86-with-glibc2.3.5". I think checking for |
|
It didn't successfully install mysql / mariadb from within Ubuntu... or at least, it didn't start it up successfully in a way that worked from the script to do the database setup. But the rest of it seems to have worked so far... |
|
This appears to be because mariadb didn't start automatically. After starting it with the command |
|
After successfully getting through the setup process on a fresh Windows 10 installation using the WSL route, my thinking is that our best option is probably to start saying that WSL is the only supported method of setting it up on Windows, and that we should remove the documentation and scripts that are for non-WSL Windows setup. Someone experienced with Windows and running Ruby without WSL is probably also going to be able to figure out the best current options for getting through the setup process based on the normal manual install instructions, but fewer and fewer new developers are going to be trying to contribute to this project with a Windows device that could run the project without WSL but isn't compatible with WSL. There are already too few who have come through the non-WSL setup path to the point where we haven't been able to maintain a working Windows setup script. I appreciate your thoughtful work on this @sharon-odhiambo . Even though this isn't going to be merged, it was really helpful for getting the setting system to a better state for Windows users. |
NOTE: Please review the pull request process before opening your first PR: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/CONTRIBUTING.md#pull-request-process
What this PR does
Screenshots
Before:
After:
Open questions and concerns
Kind;y ensure that when using Windows there are a number of commands in the prepare.js that are Unix-based and might not run in Windows. I've updated some but when you run into any error when building you can check the error log and update the commands with conditionals based on the system.