Closed K4KDR closed 5 years ago
Testing whether it will disrupt other aspects of the code now.
So this does work on my machine but it looks like it is really bad practice in a codebase intended for wide usage on any platform where people can have who knows what kind of environments set up. This article highlights some of the problems. As just one example, if someone doesn't have an interpreter called python3
in usr/bin/env
, then the code will crash right at that very first line of execution.
In the README, I've listed the two supported ways for running the code, either from:
python minxss_beacon_decoder
at the command line. Sorry I don't have a more satisfactory resolution for this one. The distribution risks of including that shebang in the code just outweigh the impact on convenience, even for my main co-developer 😕.
Thanks so much for the education - of course I know zero about what the correct way is to setup .py code for general use so the info is much appreciated! Downloading Python3 for Windows now so that I can test on that platform as well.
No problem! Honestly, this project is very much a learning experience for me too. It is SUPER helpful having such an active participant to help me catch problems, test on different platforms and with different set ups, and suggest features. This thing is so much better for the effort you've put in.
If it would not disrupt any other aspect of the code, would it be possible to place:
#!/usr/bin/env python3
on the first line of minxss_beacon_decoder.py ?
I have to add this line after each update to enable the app to be run by a mouse-click from file explorer.
While it runs fine without this directive from a command line with:
python3 minxss_beacon_decoder.py
... some users may prefer to launch the app from the graphical file explorer. Perhaps this would not matter if only Python3 was installed, but like many people I have multiple versions of Python installed.