@JourneymanGeek are you around?

yup

I have a bit of computer trouble and cannot decide if it is on topic for superuser or maybe better suited for SO

I hope you can tell me if it is within scope

Oh, sure

so, for work, I have to work with super-protected patient data. They are on a network share within a network which can only be accessed with devices from within the network.

When I am working from home, my only way for getting on a machine within the network is via a Citrix client, which starts a rather bare virtual machine, with almost nothing installed on it.

what I need to do is to develop and run Python scripts on the patient data.

ok

Last time I had to do this from home, I placed a WinPython in a folder on the network drive with the data.

and this would be running on the VM?

Yes, whatever I do, will have to be executed by the VM.

Ah... ok

So, the WinPython worked well, and I was able to work as expected.

I have also placed other portable-y apps on that drive, which work well. For example R and RStudio.

Today, I again have to do something with Python - and it seems to have a problem with being started.

First, all the exes (it comes with different IDEs) won't start

Any errors?

then I managed to open a Python prompt, which told me it doesn't support UNC paths and so started itself at C:\Windows

after some looking around, I found I can do "pushd" so I will have a mapped drive, which at first seemed to work

but when I try running the script from an IDE, it just doesn't do anything - and the console display flashes once and shows nothing at all, it is unusable

Well - its on scope for us

and when I tried running the script from something with a command line, it failed by telling me that the logging handler cannot open the path to the logfile - which happens to be the correct UNC path.

OK, and the maybe harder question - do you think it has a better chance of a good answer at SU or at SO?

I'm not sure its on topic on SO

kinda wierd that it suddenly decided not to support UNC paths

yes, I am not entirely sure either. IDEs and setting them up is ontopic, I am pretty sure about that - but this is not really "setting up"

Its very much network share wierdness

apparently it is not "suddenly"

the Internet discusses it in many contexts outside of Python

shellhacks.com/…

So question is - why did it work before?

I cannot find now the article which was giving an explanation for that design decision, I don't remember my search terms.

It worked on the day I created the installation - maybe it is not truly portable and placed some stuff in the registry.

RStudio is also that way - it is not a truly portable distribution, so every time I start it from the network drive, it acts as it was started for the first time. But at least it works with the network paths.

And WinPython is the advice one finds when searching for portable Python options.

Oh wait, hahaha, I just realized something - maybe I will be able to try it.

quack?

It is a bit like Inception, I am too far down in the rabbithole of virtualization!

so, I had used WinPython from the VM before

but there is one program which I cannot do portable, and that is Visual Studio with SSIS

MS likes to get its hooks in deeeeep

so for that, I was logged in into a different computer on the same network, via remote

and there I realized that the file prepared with the Python scripts contains an error, which I wanted to debug by rerunning the Python script

and since I have access to the same network drive from both the VM and the computer onto which I am remoted from the VM, I have been trying to start Python from the other computer

let's see if it will start from the VM

it starts, and the console works

I may not need the question!

lol

@rumtscho @rumtscho edit, purge history then move :D

Yes, I will have to do something about it

now I am still stumped, because it is still complaining about the path to the log file when started from the VM

but it seems to get partly into the correct path, so it is apparently not the share

anyway, thank you for patiently hearing out the problem - which turned out to be a PEBKAC after all

At least I hope you are so accustomed to such cases that I shouldn't be embarrassed

and, to be fair, in principle it should have worked from the other computer too, not just from the VM

I used to do desktop support :D

I was never officially a support person, but I have been closely involved in tickling information out of key users and alpha testers

at least half of them come in with the attitude of "now I will be doing wrong things and this computer person will laugh at me for being so stupid"

while my attitude is "if the user cannot orient themselves to use the program right, I have to rethink the UX"

but it does take time and skill to relax them enough that they dare make mistakes (and admit them).

Well - with 'slightly' technical folks, letting them rubber duck the problem helps

and if they can't, well that's what you're there for :D

I find this the most fascinating part of my job

letting a user loose on a software for the first time, and reverse-engineering all the wrong (and right) assumptions in their heads out of the way they interact with it

so, the script ran now

sleeves up, time to step through the offending input file with the debugger

thank you again for your support!

yay

Feel free to trashcan anything you need to :D

I think it is innocent enough now :)