Make `mill -i` to default under Windows OS

com-lihaoyi / mill

Mill is a fast JVM build tool that supports Java and Scala. 2-3x faster than Gradle and 5-10x faster than Maven for common workflows, Mill aims to make your project’s build process performant, maintainable, and flexible

https://mill-build.org/

MIT License

2.04k stars 331 forks source link

Make `mill -i` to default under Windows OS #781

Closed lefou closed 2 years ago

lefou commented 4 years ago

AFAIK, mill under Windows will only work when started with -i option. Until someone comes with proper fix it makes much sense to disable mill server mode under Windows.

See discussion https://gitter.im/lihaoyi/mill?at=5e5c146fd045e2582509fba4

sake92 commented 4 years ago

Mostly fixed in #791 😃 Works correctly but pipe returns Failed to connect to server.. (with exit code 1)
I'll try to find more time to debug that also.

DamianReeves commented 4 years ago

Is there any chance of getting some more background as to what the issue here is?

lihaoyi commented 4 years ago

https://github.com/lihaoyi/mill/issues/874

DamianReeves commented 4 years ago

874

What if you are not running on WSL for windows. I'm also trying to get this working at a powershell or cmd prompt. Things work with -i , but why is it needed?

lihaoyi commented 4 years ago

You'll have to investigate and tell us if it's needed or not, and why.

DamianReeves commented 4 years ago

If I could understand a bit more what -i is supposed to enable maybe I can understand what fails on windows. At worst though we should probably just make -i the default for windows. I'm also not sure how we discover WSL vs normal windows, and if that distinction is needed.

Also it should be noted that WSL2 has a different kernel from WSL1... I can take a look at how it executes in WSL2 as I have a machine with that installed.

lefou commented 4 years ago

Mill -i forces mill to run in a single Java process (entry point: MillMain). By default, it will run two processes, a client (entry point: MillClientMain) and a server process, which is started by the client in case there is no free running one. The communication between these two processes is the culprit on Windows. Also, because of the unclear implications of the name --interactive, we deprecated -i and introduced two new options, see #927.

sake92 commented 3 years ago

@DamianReeves I did some fixing in #1230 Can you please try to build latest mill and test if it works?
Instructions here: https://gitter.im/lihaoyi/mill?at=605dbef03b9278255bd52443

james-s-w-clark commented 2 years ago

Installed latest mill with scoop (0.10.4)
Downloaded sample project
Ran a few sample commands (mill foo.compile, mill foo.run) and checked project/out/mill-worker-.....=-1/run, saw the command updating in there (and the commands completed sucessfully)
- So, it looks like client-server mode is working correctly by default

Just doing a little more testing (running mill at the same time on two different projects). I didn't look into the "locked pipe" stuff, but I thought each server/worker gets its own directory. Package structure of the workers looks the same in MacOS and Windows anyway.... so I'd guesss each package could have 5 independent servers/workers. Will update comment and tag when I know if there's a problem/if ticket can be closed

james-s-w-clark commented 2 years ago

1 project, Thread.sleep(10_000) , 2x mill foo.run and 1x mill foo.compile → 3 workers, all fine
copy project with tiny changes in the clone
- do 3x mill moduleName.run in each project
  - each project/out directory gets 3 worker/server subfolders. The worker names all have the same prefix mill-worker-y4i2xmtm5Hv8lzskMkPKIWcZtwM=-<index>. I'm not sure what decides this naming (I thought it was a hash of the code/module names or so), but they all seem like independent workers.

@sake92 Thanks for your merge! I don't see the error you mentioned 🎉 @lefou I believe you can close this ticket :)

sake92 commented 2 years ago

@IdiosApps now we use junixsocket library which supports native Windows10 implementation of UNIX pipes, so it is much more reliable, thankfully. Glad you confirmed everything works! 🥳

Btw, you get at most 5 servers worker per JVM+project_path (if one is busy, another one will be instantiated).
See https://github.com/com-lihaoyi/mill/blob/main/main/client/src/mill/main/client/MillClientMain.java#L108

james-s-w-clark commented 2 years ago

@sake92 Nice, I'll have a little look into UNIX pipes. I'm not sure what they are in this context - I guess like sockets, from what I've seen.

Ah that makes sense, thank you for the explanation and the link! I was curious about worker folders today when looking into this issue I opened.

lefou commented 2 years ago

Closing this one, as Windows now properly supports client-server-mode. Also Mill in general is able to recover from am failing server connection by running in-process.