brinckmann / montepython_public

Public repository for the Monte Python Code
MIT License
92 stars 78 forks source link

Finding classy is broken in several ways #371

Open ThomasTram opened 3 months ago

ThomasTram commented 3 months ago

https://github.com/brinckmann/montepython_public/blob/d3e2c72e5d87bf32c5bbf3c772a54db7e1f499a8/montepython/initialise.py#L159-L174

MontePython is supposed to be able to import a specific class version based on either "default.conf" or whatever conf file is passed. In reality this is not working right now, and most people just get the classy version installed in the site repository. Let's see what happens:

classy_path is initialised to an empty string. Then we loop through all items inside python/build. If either element contains the substrings "lib." and "sys.version" classy_path is updated to be that path Note here that classy_path is always a string, never a list. The next if-statement is then puzzling:

if len(classy_path)==1:
    classy_path = classy_path[0]

It should be noted that on my machine sys.version has the value 3.11.5 (main, Sep 11 2023, 08:31:25) [Clang 14.0.6 ] which is highly unlikely to be baked into the name of the lib-directory. I renamed the lib-directory manually to see what happens then. In this case classy_path was lib.3.11.5 (main, Sep 11 2023, 08:31:25) [Clang 14.0.6 ].macosx-11.1-arm64-cpython-311 which had a length greater than 1, so we hit the else statement. Now there is a loop, for path in classy_path: which iterates over the characters in the string, checking if the substring "3.11" is part of the character, which it is not (!). Later, classy_path is then inserted in sys.path and the import happens correctly. (By the way, I also checked sys.version in the latest Python docker, and it gave 3.12.3 (main, Apr 24 2024, 14:36:30) [GCC 12.2.0]).

There are a lot different CLASS versions out there, and depending on the built environment and system, the classy shared object file can be located in many locations and have many different filenames. I suggest the following: Just add all subdirectories of class/python/build to the sys.path and let Python search through these. If there is more than one, the user should clean the python/build directory.

The try-except statement is also not very strong: as long as the python/build folder exist, MontePython will not complain, even though the wrapper was not found there. I suggest to put a warning if data.path['cosmo'] is not found within classy.__file__, because in that case the user is probably using some classy from a site repository.