[SOLVED] Recommended way to upgrade module?

[Winfried]

Hello,

When running a script on a Debian 12 host that worked fine on Windows, a method is missing because a module is older on Debian.

What is the recommended fix?

If possible, I prefer to use apt to install packages as an easy way to upgrade things.

Thank you.

Traceback (most recent call last):
  File "blah.py", line 34, in create_events_list
    for event in gcal.events:
                 ^^^^^^^^^^^
AttributeError: 'Calendar' object has no attribute 'events'

#Linux
~# pip freeze | grep icalendar
icalendar==4.0.3
~# python3 --version
Python 3.11.2

#Windows
pip freeze | findstr icalendar
icalendar==6.3.2
py --version
Python 3.13.2

apt install python3-icalendar --upgrade
python3-icalendar is already the newest version (4.0.3-5).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[Gribouillis]

If you don't use virtualenvs (you should), you can perhaps install icalendar separately for your user with

Output:
python3 -m pip install --user --upgrade icalendar

[Winfried]

Thanks, I'll check it out

[noisefloor]

If possible, I prefer to use apt to install packages as an easy way to upgrade things.

This heavily conflicts your interest. Debian and distros based on Debian are stable release distribution, which means that as a standard there will be _no_ version jump within a release. You get bugfix releases (hopefully) and that's about it. If you want to use APT only and the Python package $FOO is too old, the only way to resolve this to wait for the next Debian release and hope that the Python package needed is new enough coming from Debian's repos.

However, using virtual environments and install within those via pip packages is need is the way to go. Especially is it isolates Python packages in the venv from system's packages. Which is a _really_ (!) important point for most Linux distros, as Python and certain Python packages are integral part of the system's installation and breaking them may lead worst case to a not working Linux installation. On Windows, it's less critical, as Windows itself does not use and does not rely on Python. But it is still a very good idea to isolate different projects in different venvs.

In other words: if you don't use venvs yet -> start using them now. There is a basic explanation on venvs in the Python tutorial plus a gazillion other sites on the internet explaining it, as using venvs for Python is pretty much standard and recommended practice.

Regards, noisefloor