Repository navigation
Windows support with scoop installer without bash #198
Description
I tried to use this from windows. Unfortunately it needs a bash environment. I know that this is the intended purpose for this project.
I created a simple scoop installer but with a jar created from https://github.com/hj-lee/kscript (thanks @hj-lee ).
scoop add bucket raisercostin https://github.com/raisercostin/raiser-scoop-bucket
scoop install kscript
After that I was able to execute scripts with dependencies from windows without any bash help via a simple kscript hello.ks.
How can I help to have an official release with the merge from @hj-lee fork?
Activity
holgerbrandl commentedon Dec 4, 2018
I think PR #194 is progressing well and should improve Windows compatibility. I was under the impression that @hj-lee fork was more about start-up time improvements but it's interesting to hear that it also comes along with improved windows compatibility.
I still don't know if
kscriptcan be fixed to become fully windows compatible because certain features like custom interpreters or script-packaging will just work in bash.I've not used scoop yet, but we could add it to the list of installation options. All we'd need to do is to patch the readme and add the corresponding deployment bits to kscript_release.sh. Feel welcome to provide a PR for this feature.
hj-lee commentedon Dec 4, 2018
Actually, my PR improves platform independence a bit as it makes kscript less dependant on bash.
By default, the main script uses the kscript java process, and if it uses runtime flags(such as -Xmx), it executes Java using Java process API on Windows instead of depending on bash.
hj-lee commentedon Dec 4, 2018
Regarding PR #194, it seems @abelsromero wants to use kscript on "git-bash". It is possible that PR #194 is not helpful to build scoop distribution. Also, I think my PR can be helpful to simplify PR #194 as my PR eliminates critical bash or cmd calls (compiling and executing). (Actually, my forked master branch has other changes, and one of them is "git-bash" support.)
abelsromero commentedon Dec 5, 2018
Just for testing because there's already a test suite written in bash. I have added more unit test, but I don't know enough he code to do more changes. In the long term I'd like to cover everything with Kotlin unit tests and avoid the bash test, but that will require some refactor that I feel it's risky for my first PR.
In #194 I have implemented native Windows calls and adapted who paths are generated:
abelsromero commentedon Dec 5, 2018
That can be fixed and I'd recommend moving that conversation to #197. If we all agree that next release's goal is full Windows compatibility we just need some coordination 👍
About @hj-lee I'd really like to see some of its improvements (specially the one "calling directly the kotlin compiler instead of bash") but I don't like "use classloader to run the script main and more" (I've experienced classpath pollution in gradle plugins that add code to the classpath).
Said that, I have to say that some of @hj-lee ideas are great but having many improvements in the same branch puts the leader in a complicated position of "all or nothing". How about splitting them so we can choose with ones we want merge asap?
hj-lee commentedon Dec 5, 2018
@abelsromero, #194 may be sufficient to support scoop, then. I guess @raisercostin can see?
Regarding #102, let's continue discussion on it.
(By the way, you're welcome @raisercostin)
holgerbrandl commentedon Dec 7, 2018
thanks @hj-lee and @abelsromero for your continued efforts to improve
kscript. I've read both PRs again, and here are my thoughts - side by side to easy the discussion.Sorry @raisercostin for hijacking your ticket with this more general discusssion. :-)
194
pros
which->wherefor improved windows compatiblitycons
PR adds includes many other changes. Some are arguage
KscriptTest.ktmunclear if integration tests should not better be implemented for the shell, since kscript is a shell tool instead of jUnit. (imho they should go into the shell)
testing it on windows seems suboptimal. we should be able to run existing test_suite.sh in WSL and git-bash and have a dedicated suite for powershell.
the kscript launcher is still highly unlikely to run under powershell. What did we gain? (WSL compatiblity? git-bash compatbility?) Can kscript work in powershell at all (without a new launcher)?
102
pros
cons
KOTLIN_OPTS:argsprocessing away from shell launcher, now it's coming backOther notes
in presence of
KOTLIN_OPTSthere is no speed-improvment in #102 I think.selfUpdateshould be removed (to specific and to tied to bash). users willwant to update using their preferred method anyway.@hj-lee how does the first part before the dash relate to other second part? I dont' see how your PR would build a fat jar, and I also don't think it's a good strategy because it would make initial script run very slow in case of complex dependencies.
Clearly smaller PRs are easier to merge. However its a bit tedious to create multiple PRs for every miniscule change, because they need to go into separate branches of the fork. So pooling them into a big-mother-of-all-PRs makes life much easier. :-)
Both #102 and #194 seem to stray from their original indent to some extent, but I can indeed cherry pick changes instead of a full merge as needed. So no need to split anything up.
Summary
To me #194 is a more incremental workaround for an improved windows compatbility which comes with some unclear/uneeded other changes (listed above). I may exclude these from the merge, which I'll try to do in the next days. But even with the PR, windows compatbility of kscript seems imho not really ready for primetime (missing powershell lancher, missing CI like using appveyor).
Clearly #102 goes much deeper by changing the execution model. This definitly results in a cleaner design without so many external tool invocations. However, because I care about backwards compatiblity much more than about a slightly faster execution, I don't feel ready yet to merge it because of my concerns/questions listed above). Once these are resolved, #102 is clearly the way forward.
abelsromero commentedon Dec 8, 2018
I tested several way and found no other that worked fine con cmd. :%
I don't know what do you mean, I created the tests to help me test & and specially debug. They are not perfect, but the tests are the problem, feel free to delete them.
The dependency resolution is the result of the rebase from the master with #159.
I understood that was OK to be added in a separate PR.
We can add a ".bat" similar to how gradlew works. Do you think this will suffice?
holgerbrandl commentedon Dec 10, 2018
Sorry for the confusion. I meant the change e4c34d6#diff-71918461924a453d7a1654dcc529ba78R39
It may be a sound improvement, but the intent is not really clear to me yet.
You already added some new tests, so my question/comment was rather about why the current tests are not sufficient to cover windows (e.g. when using
kscriptin a git-bash environment). I was initially under the impression that we wanted to fixkscriptto pass the existing tests on windows first, and add more CI for git-bash, powershell, etc. later.I have worked too little with windows in the last years, I don't know what the best practice would be. Providing a
*batversion seems like a solution, but sincekscriptwas intended to be used mainly as an interpreter (via shebang), so I'm not sure ifkscript.batwould work.holgerbrandl commentedon Dec 10, 2018
Sorry for the confusion. I meant the change e4c34d6#diff-71918461924a453d7a1654dcc529ba78R39
It may be a sound improvement, but the intent is not really clear to me yet.
You already added some new tests, so my question/comment was rather about why the current tests are not sufficient to cover windows (e.g. when using
kscriptin a git-bash environment). I was initially under the impression that we wanted to fixkscriptto pass the existing tests on windows first, and add more CI for git-bash, powershell, etc. later.I have worked too little with windows in the last years, I don't know what the best practice would be. Providing a
*batversion seems like a solution, but sincekscriptwas intended to be used mainly as an interpreter (via shebang), so I'm not sure ifkscript.batwould work.abelsromero commentedon Dec 15, 2018
Can't recall exactly why I did this in e4c34d6#diff-71918461924a453d7a1654dcc529ba78R39 other than the fact that "./" does not wok for a windows path with "", and that this solution works fine for all OSs.
That's the standard approach, just check how gradle wrapper does.
BTW: I have to attend some thing following weeks :% so I think is better to close all other PRs first. After that I will create a new one from master including the changes and comments manually to avoid mix the git history. Is that OK?
holgerbrandl commentedon Dec 16, 2018
Sure. If possible keep the new PR as focused as possible to easy merging.
holgerbrandl commentedon Jun 24, 2019
Windows support has improved considerably (still relies on gitbash but this is per design), so I'm closing this ticket.
pmatysek commentedon Sep 30, 2021
Can someone give me advice how to use kscript on Windows?
I should add to the script something like that?
#!C:\Program Files\Git\git-bash.exe kscriptIt shows me error
[kscript] [ERROR] kotlinc is not in PATH, but kotlinc surely is in PATHholgerbrandl commentedon Sep 30, 2021
pmatysek commentedon Oct 11, 2021
As I said before kotlin was in path. So I've made some investigation and testing. As I figured out problem was with
bash -ccommand. For some reason it's not showing any output neither while running on my windows cmd nor from kscript. There wasn't any output even from simpleecho. Fortunately I found that commandsh -cis working perfectly.For that reason I wrote some piece of code which is choosing proper bash command for OS, here: #331
However I'm not sure if problem is only in my enviroment (with git-bash instalation or some windows configuration?) or global for windows.
holgerbrandl commentedon Oct 23, 2021
Thanks for your clarifying description. Though, I'm not sure how to fix/incorporate that into kscript.