bitranox/lib_programname

Determining the Name of a Process from Python

lib_programname's Issues

lib_programname not found by PyInstaller

• **I'm submitting a ... **

  • bug report
  • feature request
  • [ x] support request

• Do you want to request a feature or report a bug?

• What is the current behavior?
  In python script, use:
  import lib_programname
  logName = Path(lib_programname.get_path_executed_script()).stem + '.log'
  This works fine from the interpreter.

Now, use PyInstaller to build your application.
In the PyInstaller warn file I see:
missing module named lib_programname - imported by C:\Users\me\PycharmProjects\YouTube Utils\utterance_browser.py (top-level), myUtilities (top-level)

Unsuprisingly, if I run the resulting .exe I get:
ModuleNotFoundError: No module named 'lib_programname'
[21572] Failed to execute script 'comments_browser' due to unhandled exception!

My PyInstaller command line is:
pyinstaller myUtilties.py --clean --noconfirm --collect-data 'lib_programname'

I've also tried creating a .spec file and adding:
hiddenimports=['lib_programname'], which produces the same results as above.

• **If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  PyInstaller finds lib_programname and allows it to work with it's generated executable.

• What is the motivation / use case for changing the behavior?
  You can use PyInstaller to generate multiple exes, one for as many separate scripts as you desire. Each of those exe's should log errors to a log file formed from their name. This works great with lib_programname running in the interpreter, just not in the exe's produced by Pyinstaller

• Please tell us about your environment:

• Release Number of the Repository used : lib_programname 1.1.8
• Python Version : 3.9
• OS, OS Version : Windows 10

• Other information (e.g. detailed explanation, stack traces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow
  , gitter, etc)

Fails to resolve program name if launch name lacks extension

• **I'm submitting a ... **

  • bug report
  • feature request
  • support request

• Do you want to request a feature or report a bug?
  Reporting a bug.

• What is the current behavior?
  lib_programname fails to resolve the program name correctly when the program or a symbolic link pointing to the program has no extension.

• **If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

$ # the test script
$ cat test.py
#!/usr/bin/env python3
import lib_programname
# this returns the fully resolved path to the launched python program
path_to_program = lib_programname.get_path_executed_script()  # type: pathlib.Path
print(path_to_program)

$ # running the script directly works
$ ./test.py
/Users/tester/test.py

$ # running the script with a .py named symlink works
$ ln -s test.py link2test.py
$ ./link2test.py
/Users/tester/test.py
$ rm link2test.py

$ # running the script with a symlink without an extension fails
$ ln -s test.py link2test
$ ./link2test
/usr/local/lib/python3.9/site-packages/lib_programname/lib_programname.py

$ # running the script directly also fails if it has no extension
$ mv test.py testme
$ ./testme
/usr/local/lib/python3.9/site-packages/lib_programname/lib_programname.py

$ # running the extension-less script with a .py named symlink works!
$ ln -s testme link2test.py
$ ./link2test.py
/Users/tester/testme

• What is the expected behavior?
  ./link2test should have reported the same as ./link2test.py: /Users/tester/test.py

• What is the motivation / use case for changing the behavior?
  N/A

• Please tell us about your environment:

• Release Number of the Repository used : latest
• Python Version : 3.9.4 via brew install python3
• OS, OS Version : macOS Mojave

• Other information (e.g. detailed explanation, stack traces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow
  , gitter, etc)
  The minimal demo above indicates the program/script name is correctly resolved if the script or the link to the script has a .py extension, but fails if the script or link being executed has no extension. The last case is interesting, as the link has an extension, but the script does not, yet lib_programname resolves the script name correctly, which confirms this issue only occurs if the launch name (script or symlink executed) has no extension.