Repository navigation
Python implementation of kscript #232
Description
I would like to create a Python implementation of kscript for ease of use on Windows machines without cygwin or other solutions and easy distribution through PyPI and conda.
As far as I can tell, the relevant bash code for kscript lives in src/kscript. I searched this repo for "env bash" and a few more files showed up (on commit ba74b62):
misc/experimental/kscriptJarStubmisc/experimental/kscriptDtest/resources/custom_dsl/mydslmisc/kshell_launcher/kshell_kts.shmisc/docker_tests.shtest/test_suite.shsrc/main/kotlin/kscript/app/AppHelpers.kt
I assume that anything with test or experimental in it would not be relevant for a Python implementation (for now), leaving only kshell_kts.sh and AppHelpers.
Is AppHelpers.packageKscript intended to be run on the client machine? If yes, the use of bash may be prohibitive for a Python implementation of kscript.
Other issues are:
- Should a Python implementation live in a separate repository or within the kscript main repository?
- Potential name clashes of the python
kscriptexecutable with the existingkscriptbash script
Possibly related: #36
Activity
holgerbrandl commentedon Jul 1, 2019
Indeed, you could ignore
experimentalandmisc. You need to widen your search by also includingevalBashbecause kscript is actually launching a few shell processes internally to compile code etc.Feel welcome to reimplement it, but for windows compatibility, you just need a bash shell (like git-bash) and bash on the PATH. This works for me, and if it does not for you, I'd consider it a bug that we should address.
Yes, packaging is intended to run on the client machine. See https://github.com/holgerbrandl/kscript#deploy-scripts-as-standalone-binaries
kscript is a shell tool. I'm not sure how to remove its dependency on the shell without rewriting it. So a python version should deserve an own repo imho. And to prevent user confusion a different name for the executable would clearly help.
hanslovsky commentedon Jul 2, 2019
I am a Linux user and not too familiar with Windows, but I would still like to make code available for use on Windows. I will investigate if git-bash is a viable solution in practice. A little overhead on the client side for installation is preferable to a complete re-implementation in Python, especially as git-bash is available on conda. I will look into it and report my decision
holgerbrandl commentedon Jul 2, 2019
I think the best approach for better platform interop would be to refactor ìnteral
evalBashaway. Next, the shell launcher itself could be easily reimplemented in any scripting lang and we could potentially even bundle it with the current installation bundles.Another approach for better platform compatibility would be to use the kotlin compiler api (see #205).
holgerbrandl commentedon Sep 2, 2019
I'm closing this ticket because it does not seem an issue with
kscriptitself.