How to detect code is running from a Pynsist installation

[carlosperate]

Is there a way during runtime to determine if the code is running from a Pynsist installation?
I had a look at the docs and issue tracker, but didn't find anything.

PyInstaller has sys.frozen: https://pyinstaller.readthedocs.io/en/v3.3.1/runtime-information.html
Briefcase has PEP 566 package metadata: beeware/briefcase#425

Does Pynsist have something similar?

[takluyver]

There's no specific way to check this. It's meant to be not such a weird configuration as freezing an application, so it shouldn't need special casing in the same way. What specific behaviour do you want to achieve? I'd suggest that it's better to focus on specific conditions - e.g. is the directory this module is in writable - rather than labeled situations. There's an analogy here with frontend web development. It's really tempting to check for specific browsers, but it's usually better to check if the features you want to use are available.

…

On Fri, 4 Sep 2020, 11:22 Carlos Pereira Atencio, ***@***.***> wrote: Is there a way during runtime to determine if the code is running from a Pynsist installation? I had a look at the docs and issue tracker, but didn't find anything. PyInstaller has sys.frozen: https://pyinstaller.readthedocs.io/en/v3.3.1/runtime-information.html Briefcase has PEP 566 package metadata: beeware/briefcase#425 <beeware/briefcase#425> Does Pynsist have something similar? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#207>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQB5MXP4YXK34TKZNUTALSEC5WLANCNFSM4QX7OQIQ> .

[takluyver]

I'll leave this open for now because I'm interested to collect views (@carlosperate's or anyone else's) on what specific things people want to achieve with such a feature.

My gut feeling is that this would be a bad idea. Code installed by Pynsist shouldn't need to know how it got there. It should just be some Python code, running on Windows. Any special behaviour for the installed application is another corner for bugs to hide in. But I don't want to be dogmatic about this - maybe there's a real use case I don't know about.

[carlosperate]

Sorry for the late reply @takluyver, I somehow missed the original response.

There's an analogy here with frontend web development. It's really tempting
to check for specific browsers, but it's usually better to check if the
features you want to use are available.

That's a very good point and I agree.

My original request was for a an old Mu use case in which a config file could be loaded from the project root when running from source code, or from the same folder where the packaged executable is running from (back when it was using PyInstaller).

[takluyver]

Thanks!

For the use case of finding a config file, I might be tempted to suggest either:

• Have a search path of several locations, and load config from the first place where it's found (or load all available config and merge them, depending on the application)
• Or treat running from an installation (with config presumably in some user directory) as the normal case, and running from a source checkout without installing as the special case to detect - e.g. by checking for some marker file which doesn't get installed.

[carlosperate]

Thanks @takluyver.
Going through different search paths is the current implementation, where it tries to figure out if it's packaged based on directories structures, it's just that because different platforms have been packaged differently, you end up with a few different checks that could break if the packaging software changes something. That's the reason why having a canonical way to first check what mode the application is running was appealing.

Or treat running from an installation (with config presumably in some user directory) as the normal case, and running from a source checkout without installing as the special case to detect - e.g. by checking for some marker file which doesn't get installed.

That's a good idea as well, thanks! We could add that as another check as well.

Thank you for your time and help! I completely understand your point of view herel, so if this feature falls out of scope for pynsist feel free to close the ticket 👍

[takluyver]

Is this a fixed config file that gets installed as part of the application and not changed? Or something that gets modified by the user (possibly via some settings editor)?

I think this might be an XY problem - where X is 'how can we find this config file in all scenarios', and Y is 'how can we detect which of these N specific scenarios the code is running in'. I.e. I suspect that there may be a better solution which doesn't involve figuring out which scenario it's in. But I don't want to be high-handed about this - you're the one working on an application and you know what it needs better than I do. Maybe detecting a Pynsist installation is a sensible thing to do! But I'd like to understand the use case better.

[albertogomcas]

As mentioned in my comment: #216 (comment) the package metadata is not available on a pynsist app, so one could abuse this fact to detect that the code is running from an installed copy.

However, it would make me happy if the metadata would be available so maybe is a short-lived workaround...