18:34 <headius[m]> enebo: hey what Rails are you using to verify Windows?

18:34 <headius[m]> https://github.com/jruby/jruby/issues/6648

18:34 <headius[m]> we probably should bump it to one that tries to install this gem

18:35 <enebo[m]> Last Rails 5 before 6

18:35 <headius[m]> RG tweaked the extconf process launch to pass env vars and that is apparently not working in Windows process launching code

18:35 <enebo[m]> It occurs to me that .16 was last time I checked to see if sassc had been fixed

18:35 <headius[m]> so this is broken for all ext builds on Windows, but sassc is probably the most common one we'll see

18:36 <enebo[m]> but I did run sassc and install it for .17 but it was the one shipped for rails 5.2

18:36 <enebo[m]> that presumably is not a different install mechanism is it?

18:36 <headius[m]> sassc or the Ruby one?

18:37 <headius[m]> I don't see how any sassc ext build would work with this issue

18:37 <headius[m]> if it extconfs it is broken

18:37 <enebo[m]> oh I don't know...I just run rails and I was only running 5.2 because of the rails 6 sassc thing

18:37 <headius[m]> yeah prior to rails 6.0.1 they still used the ruby one

18:38 <enebo[m]> well up to this point rails 6 has not worked for windows for us so this just changed the error

18:38 <enebo[m]> so this is not a regression in that sense

18:39 <enebo[m]> I am happy to see they fixed windows overall though

18:39 <headius[m]> well that is fair

18:39 <enebo[m]> they fix it and our rg upgrade breaks it :)

18:40 <headius[m]> yup

18:40 <headius[m]> never upgrade anything

18:40 <enebo[m]> But one extconf is fixed we can figure out anything else and guarantee 6+ is good again on windows

18:40 <headius[m]> yeah this needs process launching help to accept env

18:40 <headius[m]> that is pretty much it

18:40 <enebo[m]> ack!

18:40 <headius[m]> I will try to come up with a minimal fix but Windows process launching continues to fall behind

18:41 <enebo[m]> so jnr-posix or poetntially avoidable

18:41 <enebo[m]> I am not sure if we are current with jnr-posix or not

18:41 <headius[m]> nothing in jnr-posix can help because we can't use posix_spawn on Windows

18:41 <headius[m]> the long term fix is to wire up Windows process launching with the appropriate win32 functions

18:41 <enebo[m]> There is just a lot of windows process launching code in jnr-posix and we do use that for something

18:42 <headius[m]> but it should be easy short term to get the env to propagate into JVM launcher

18:42 <enebo[m]> we determined that a few months ago I thought

18:42 <headius[m]> yeah I just mean that is a longer term thing to get wired in

18:42 <enebo[m]> ok

18:42 <headius[m]> but it could happen for 9.3 if we have time 😀

18:42 <enebo[m]> yeah

18:43 <headius[m]> the launching code there is not useful for general purpose subprocesses in its current form

18:43 <headius[m]> but it is a start

18:43 <enebo[m]> It was just a port of some ruby launching code

18:43 <enebo[m]> from quite a while ago

18:43 <headius[m]> ok

18:43 <enebo[m]> so it has some semblance to what MRI did at some point in history

18:44 <enebo[m]> such is life

18:44 <headius[m]> yeah

20:48 <headius[m]> enebo: https://github.com/jruby/jruby/pull/6649

20:49 <headius[m]> unfortunately open3 is not a default gem so we can

20:49 <headius[m]> can't really work around this easily

21:14 <headius[m]> enebo: this is a larger issue than I thought

21:15 <headius[m]> it was previously using IO.popen which worked reasonably well... but it now switched to open3 which has poor support for Windows on JRuby, so it is not just a matter of fixing one spawn form, they are creating IO pipes and such that we can't propagate through JDK Process

21:18 <headius[m]> We have some partial patches in open3 for Windows but not these paths. I will try to add more there