Yeah, would be happy to do so, just haven’t had time to look at it

Hi @alexmiller, any chance you can review the above please? I can submit an initial draft if you think it worth fixing, thanks

it's worth fixing. if you know what to fix, happy to take a pointer

or is that in there

I don't think it should explicitly throw but if there is a way to convey the error level through, that would be good

It appears to me as if throwing is the Powershell way to indicate failure, you get these ugly exception messages all over the place in PS. I will research a bit more and come back with any new findings ...

I don't think that's right

have you tried looking at $LASTEXITCODE ? that seems to be the powershell way

I don't know if that's conveyed through the ClojureTools psm though

Yes, this is the challenge we need to convey failure both when running from the cmd prompt (i.e. when invoking with (1) powershell -command clojure and (2) when we run clojure from within the powershell). The $LASTEXITCODE is just the exit code of the last subprocess invoked from Powershell, we need to do exit $LASTEXITCODE to convey it to the parent process that called powershell, but this will exit the shell. So if you bring up a shell and run clojure and it exist with exit $LASTEXITCODE you will be thrown out of the shell

so we need a way to both get an exit > 0 when invoking as powershell -Command clojure and when calling clojure from within powershell (then we need to check the $? variable). The only way I figured out how to do this is to throw an exception, which does the job but gives an ugly powershell message out as usual

Let me review any public PowerShell scripts out there to see how they handle this and see what else I can find, if anything

Hi @alexmiller, I've reviewed a few public PS repos on GH but couldn't find something explicit to our situation. A relevant example I found is a fn to invoke native executable at https://github.com/PowerShell/PowerShell/blob/master/tools/buildCommon/startNativeExecution.ps1, which throws an exception when the exec returns a non-zero exit code. I also found the following answer in stackoverflow, which I think is relevant, although it only refers to the $? variable when running a command from within powershell https://stackoverflow.com/a/58968489, but also covers the case where powershell is invoked from the command prompt (or as an external process). To quote the relevant part: For now, these are the only ways to cause $? to reflect $false in the caller's scope, and, conversely, you cannot always ensure that it is $true: • From a script: Exit the script with exit <nonzero-integer> • From a cmdlet or function (script as well): ◦ Throw a script-terminating error (`Throw`) or a statement-terminating error (`$PSCmdlet.ThrowTerminatingError()`) - the latter being only available in advanced functions and scripts. Let me know if you think we need more help to decide on the correct fix, and I could perhaps post a question to stackoverflow. Thanks

Hi @alexmiller, I submitted a question to stackoverflow wrt above, and there does not seem to be a much better answer than the original suggestion of throwing an exception to indicate failure of the Powershell ClojureTools module. The other alternative suggested is to create an additional wrapper .ps1 script around the ClojureTools module, install it at the user workstation somehow separately from the module, and call Cllojure via that wrapper file with powershell -File command. The disadvantage with this approach is that an additional script is needed to be installed somewhere within the reach of the PowerShell path, though it eliminates the issues with the original approach (ugly exception message, can return the actual exit code) https://stackoverflow.com/questions/74244663/how-to-best-indicate-failure-of-a-powershell-module-to-the-calling-shell-process

What do you think?

I think this is probably not worth doing if we're going to deprecate the powershell anyways

I completely agree! Though, just to make sure and apologies for me being annoying, are you 100% onboard with switching to deps.clj in the near future and confident that we can address all the remaining details? (the first thing that comes to my mind is whether you are going to take ownership of the project or leave it to the community and how this will work)

I am still expecting to move in that direction, not sure of the details yet

Sounds good. Do you feel confident this is likely to be achieved in the short/mid term?

I'm only asking because if not, we should still continue to provide some level of support to the current implementation IMHO

well the new path exists now, so it has "been achieved" at some level already and I don't think the differences going into the future will be much different at use time, but more likely at install time

https://github.com/casselc/clj-msi

I'd be interested in your feedback in trying to use that instead of the powershell version

Yes, I've been following the latest news, and it looks really good. What I'm not sure is whether you are planning to endorse it as a replacement for the current PS implementation at some point (mainly recommended as the way to go on MS-Windows on the official clojure website), or are we going to end up with two implementations, one that you control as always, and the other driven by the communicate playing catch up 🙂

Yes I will give it a go and report back to you with my findings. It looks good so far.

my plan would be to deprecate and stop making the powershell one