"NameError: name 'calendar' is not defined" when running calendar-cli

[poisonborz]

After installing on Ubuntu (and interestingly, in Windows) and running calendar-cli, a python error is shown:

Traceback (most recent call last):
  File "calendar-cli", line 1, in <module>
    calendar-cli.py
NameError: name 'calendar' is not defined

[tobixen]

Did you install from the master branch? How was it installed?

The last commit I did seems to be broken, but your error message still doesn't make sense to me. I currently get this error message when installing it and running it:

$ calendar-cli
Traceback (most recent call last):
  File "/usr/bin/calendar-cli", line 4, in <module>
    __import__('pkg_resources').run_script('calendar-cli==0.14.0.dev0', 'calendar-cli')
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 672, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 1479, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/lib/python3.10/site-packages/calendar_cli-0.14.0.dev0-py3.10.egg/EGG-INFO/scripts/calendar-cli", line 41, in <module>
ModuleNotFoundError: No module named 'metadata'

[tobixen]

I'm a bit busy right now, but I will try to fix the error above during the day.

[poisonborz]

Did you install from the master branch?

Yes, cloned the master branch and executed the setup file.

[tobixen]

Sorry the delay. Can you try again?

[poisonborz]

Sadly the issue is not fixed.
Exact steps:

• checkout the repo
• install deps with python3 ./setup.py install - this succeeds with Finished processing dependencies for calendar-cli==0.14.0.dev0
• navigate to bin and execute calendar-cli

Traceback (most recent call last):
  File "/usr/local/bin/calendar-cli", line 4, in <module>
    __import__('pkg_resources').run_script('calendar-cli==0.14.0.dev0', 'calendar-cli')
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 667, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1470, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/local/lib/python3.8/dist-packages/calendar_cli-0.14.0.dev0-py3.8.egg/EGG-INFO/scripts/calendar-cli", line 1, in <module>
    #!/usr/bin/python3
NameError: name 'calendar' is not defined

[tobixen]

That's a very weird traceback. What happens if you try the kal command? What happens if you run python ./bin/calendar-cli.py from the calendar-cli directory?

[tobixen]

And what version of python do you use? (I'm on 3.10.8, not able to reproduce - I should set up github to run the test over different python versions eventually)

    __import__('pkg_resources').run_script('calendar-cli==0.14.0.dev0', 'calendar-cli')

I'd daresay the problem is with the dash up there. It's a bit strange it's still there, I've done my best to rename the package from calendar-cli to calendar_cli to avoid such problems. Perhaps I should read more on packaging and try to update setup.py to the "best current practice".

[poisonborz]

python ./bin/calendar-cli.py from the calendar-cli directory?

Yes, this works! Running both executables in other ways results in the error above. My Python version is 3.8.10.

[tobixen]

I still can't understand it. The traceback ends up on the shebang (#!/usr/bin/python3). It does find it's way to the calendar_cli-file. And the NameError given hints that a variable calendar is accessed but not defined in the script. Very weird, and I need to figure out of this before the next release.

[tobixen]

Ubuntu 20.04? I guess my best shot is to install the package on the same environment and see if I can reproduce it.

[poisonborz]

Yes, 20.04 LTS. More specifically in WSL.

[tobixen]

WSL?

I tried this on two relatively clean Ubuntu 20.04.5 LTS servers, I was not able to reproduce the problem.

[poisonborz]

I tried to execute it with Python 3.10 (python3.10 calendar-cli.py) but the result is the same. As said, the workaround of adding the /bin/ path works so I can use this, the issue could be closed until someone reports something similar again.