initialise.py determine classy_path issue

[taladi]

Hi,

I've tried running MontePython with two different versions of CLASS, specifying path['cosmo'] in the .conf file accordingly.
However, for one of the versions I got an error saying CLASS did not read parameters so and so.

After trying to debug this, I narrowed it down to the initialise.py module, where it runs:

...
try:
    classy_path = ''
            data.path['cosmo'], "python", "build")))
    for elem in os.listdir(os.path.join(
            data.path['cosmo'], "python", "build")):
        if elem.find("lib.") != -1 and elem.find(sys.version)!=-1:
            classy_path = os.path.join(
                data.path['cosmo'], "python", "build", elem)
        if len(classy_path)==1:
            classy_path = classy_path[0]
        else:
            stringcheck = "%i.%i"%(sys.version_info.major,sys.version_info.minor)
            for path in classy_path:
                if stringcheck in path:
                    classy_path = path
                    break
...

I found that elem.find(sys.version) will always return -1 since sys.version returns '3.11.3 (main, May 15 2023, 15:45:52) [GCC 11.2.0]' while the classy file name is lib.linux-x86_64-cpython-311. Therefore MontePython reads CLASS from the default environment library instead of the path['cosmo'] location.

I cross checked the behavior on both the Linux cluster and my macOS machine and the classy file name is similar.

I've improvised a workaround by replacing the condition as follows:

if elem.find("lib.") != -1 and elem.find(sys.version[:4].replace('.', ''))!=-1:

One can also remove the sys.version condition altogether if it is of no concern...

[brinckmann]

Hi,

I've never seen this issue before. Do you think it might be related to a recent Python change? What version of Python are you using?

You gave me the impression it only happens sometimes, for some of your CLASS versions, is this right? Do you understand why?

Best,
Thejs

[taladi]

I don't think this is a Python version issue, since I tried an online python interpreter with Python 3.7 and I got the same behavior for sys.version... I did check on other machines and the name of the lib. directory always ends with the digits without . separator, e.g. lib.macosx-10.9-x86_64-cpython-311.

I use Python Python 3.11.3.

It always happens. In my case, I encountered the error only when calling one of the CLASS versions as the other had its library copied to the default PATH of the system (since it was the last one I compiled). But say I compile a third version of CLASS then MontePython would read it and not the one I indicate in my .conf file.

The bottom line is that MontePython does not add the new classy_path and therefore does not use the desired CLASS instance.

Cheers,
Tal

[brinckmann]

Hi Tal,

Thanks, that's helpful! I'll see what's the best option for restoring the intended behavior. Now that you mention it, I've always recompiled the CLASS version I wanted to use to make sure that I get the right CLASS version and that shouldn't be the case and I thought it didn't used to be.

Best,
Thejs

[tkarwal]

I'm having the same issue. But Tal's fix didn't work for me =( (thanks though, Tal!)
I'm going to remove the classy binaries and try again.
Any update on a fix to the issue?