pymol 2.5.0+dfsg-1build6 fails to start on noble

Bug #2061036 reported by Jack Howarth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pymol (Ubuntu)
New
Undecided
Unassigned

Bug Description

The python 3.12 in use on noble causes pymol in the pymol 2.5.0+dfsg-1build6 to fail on the command line with the error...

Traceback (most recent call last):
  File "<frozen runpy>", line 189, in _run_module_as_main
  File "<frozen runpy>", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/pymol/__init__.py", line 81, in <module>
    from imp import find_module
ModuleNotFoundError: No module named 'imp'

Commenting out the line...

# from imp import find_module

in /usr/lib/python3/dist-packages/pymol/__init__.py appears to be sufficient to allow pymol to run.

Revision history for this message
Jack Howarth (jwhowarth) wrote :
Download full text (3.4 KiB)

I am a bit confused as to why simply commenting out the import of imp works as find_module() should be removed in python 3.12 under Ubuntu 24.04. There doesn't appear to be any fixes yet upstream in Debian Sid which uses the same 22_fix_pymol_import.patch. Debian doesn't have a bug report yet against python3-pymol which isn't surprising as their python3 is still at 3.11.8 in Sid.

Upstream python claims the workaround is to replace find_module with find_spec() but I can't find a clear concise example of that coding. Here is the relavent section of the documentation.

5.3.4. The meta path
When the named module is not found in sys.modules, Python next searches sys.meta_path, which contains a list of meta path finder objects. These finders are queried in order to see if they know how to handle the named module. Meta path finders must implement a method called find_spec() which takes three arguments: a name, an import path, and (optionally) a target module. The meta path finder can use any strategy it wants to determine whether it can handle the named module or not.

If the meta path finder knows how to handle the named module, it returns a spec object. If it cannot handle the named module, it returns None. If sys.meta_path processing reaches the end of its list without returning a spec, then a ModuleNotFoundError is raised. Any other exceptions raised are simply propagated up, aborting the import process.

The find_spec() method of meta path finders is called with two or three arguments. The first is the fully qualified name of the module being imported, for example foo.bar.baz. The second argument is the path entries to use for the module search. For top-level modules, the second argument is None, but for submodules or subpackages, the second argument is the value of the parent package’s __path__ attribute. If the appropriate __path__ attribute cannot be accessed, a ModuleNotFoundError is raised. The third argument is an existing module object that will be the target of loading later. The import system passes in a target module only during reload.

The meta path may be traversed multiple times for a single import request. For example, assuming none of the modules involved has already been cached, importing foo.bar.baz will first perform a top level import, calling mpf.find_spec("foo", None, None) on each meta path finder (mpf). After foo has been imported, foo.bar will be imported by traversing the meta path a second time, calling mpf.find_spec("foo.bar", foo.__path__, None). Once foo.bar has been imported, the final traversal will call mpf.find_spec("foo.bar.baz", foo.bar.__path__, None).

Some meta path finders only support top level imports. These importers will always return None when anything other than None is passed as the second argument.

Python’s default sys.meta_path has three meta path finders, one that knows how to import built-in modules, one that knows how to import frozen modules, and one that knows how to import modules from an import path (i.e. the path based finder).

Changed in version 3.4: The find_spec() method of meta path finders replaced find_module(), which is now deprecated. While it will continue to work without cha...

Read more...

Revision history for this message
Jack Howarth (jwhowarth) wrote :

It appears that the following does find the pymol module when executed within python3.12.

% python3.12
Python 3.12.2 (main, Feb 10 2024, 11:33:20) [Clang 15.0.0 (clang-1500.1.0.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib.util import find_spec
>>> print(f".libs imports {find_spec('pymol')}")
.libs imports ModuleSpec(name='pymol', loader=<_frozen_importlib_external.SourceFileLoader object at 0x1035b81a0>, origin='/opt/local/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/pymol/__init__.py', submodule_search_locations=['/opt/local/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/pymol'])

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.