Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port bash scripts to PowerShell for Windows #872

Open
jwoertink opened this issue Oct 12, 2024 · 3 comments · May be fixed by #867 or #875
Open

Port bash scripts to PowerShell for Windows #872

jwoertink opened this issue Oct 12, 2024 · 3 comments · May be fixed by #867 or #875
Labels
hacktoberfest Valid Issue for Hacktoberfest

Comments

@jwoertink
Copy link
Member

Required for #868 we need to have all of the bash scripts used for setting up the Lucky app ported over to PowerShell for Windows.

@jwoertink jwoertink added the hacktoberfest Valid Issue for Hacktoberfest label Oct 12, 2024
@jwoertink
Copy link
Member Author

@mdwagner I'm really not understanding how this Earthly stuff will work with Windows and the static fixtures. If you happen to find yourself bored sometime, I'd love a second set of eyes on this 😄

@jwoertink
Copy link
Member Author

Ref: #867 (comment)

I had a thought on this... what if instead of using bash/powershell, it was just a Crystal bootstrap? Would be nice if it could just be Ruby or something to make it a lot faster, but that means a new language requirement. We at least know Crystal will exist when this runs, and things like yarn can just run through Process.

This whole setup script process currently runs several compilations anyway. I think moving to a single Crystal script that just calls the tasks directly would actually make the whole thing faster.

Process.run("shards install")

puts "Installing node dependencies"
Process.run("yarn install --no-progress")

Process.run("yarn dev")

# this replaces lucky db.create, lucky db.verify_connection, and lucky db.migrate
Db::Setup.new.call

Db::Seed::RequiredData.new.call
Db::Seed::SampleData.new.call

@jwoertink
Copy link
Member Author

jwoertink commented Nov 11, 2024

I just thought of a downside to this.... One of my favorite features in Lucky is when I go to boot my app on monday morning for work, and it stops to tell me I haven't started all of the necessary services I need to run the app. This is especially great because it takes my app 2 minutes to compile and boot, and waiting that time just to find out redis isn't running would be very annoying....

system_check: script/system_check && sleep 100000

Now if we move this to Crystal, that means this will take a lot longer to run. On smaller apps it would be negligible, but in larger apps you may be waiting a minute just to find out stuff needs to boot... I guess we just run with this for now and see how it goes.

Edit

Well, this is surprising, and maybe this can't be directly related, but here's a fresh 1.3.0 app running the setup script as it currently stands:

real	1m10.640s
user	1m27.624s
sys	0m38.165s

And here is my take on the Crystal version of this

real	0m43.874s
user	0m41.694s
sys	0m20.983s

One thing I realized is I can't use the Db::.... tasks directly because those require lucky_task which doesn't exist until after you've ran shards install which is ran by this file... a whole catch 22. So I have to just run the lucky db cli tasks through Process.run. Even with that, it seems this is still faster by a little bit. I also noticed that colors weren't showing with the bash version, but they do with the crystal version.

I still think we'll see some issues with lucky dev in larger apps running the system check, but at that point you can come up with your own custom version (i.e. rollback to bash, or handroll some power shell if you want)

jwoertink added a commit that referenced this issue Nov 12, 2024
@jwoertink jwoertink linked a pull request Nov 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hacktoberfest Valid Issue for Hacktoberfest
Projects
None yet
1 participant