Frame config broken with 0.7.3

[saimn]

Hi Ole,

I upgraded to 0.7.3 from PyPI and it looks like the frame config values are broken:

In [1]: import cpl; cpl.Recipe.path = '/home/conseil/.local/lib'; print(cpl.__version__)
0.7.3

In [2]: recipe = cpl.Recipe('muse_bias'); recipe.tags, recipe.output
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-1b23d945e4ce> in <module>()
----> 1 recipe = cpl.Recipe('muse_bias'); recipe.tags, recipe.output

~/lib/python-cpl/cpl/recipe.py in output(self)
    360         raised.
    361         '''
--> 362         return dict((c[0][0], c[2]) for c in self._recipe.frameConfig())
    363
    364     def __call__(self, *data, **ndata):

TypeError: 'NoneType' object is not iterable

This seems to be caused by https://github.com/olebole/python-cpl/commit/4ae95bd3f19fb91e7bec9a63d5becebb37d326c2 If I come back to the parent revision of this commit, then it works as expected:

In [1]: import cpl; cpl.Recipe.path = '/home/conseil/.local/lib'; print(cpl.__version__)
0.7.2

In [2]: recipe = cpl.Recipe('muse_bias'); recipe.tags, recipe.output
Out[2]: (['BIAS'], {'BIAS': ['MASTER_BIAS']})

I tried to find why this apparently simple change break things but it does not make sense to me. I'm using cpl 7.1

[olebole]

The questioned commit just adds the version 7.1 to the list of supported CPL versions, and the only effect it has is to issue a warning in case a different version was used.

For me, this all works nicely (all from current Debian testing):

>>> import cpl
>>> cpl.__version__
'0.7.3'
>>> bias = cpl.Recipe('muse_bias')
>>> bias.cpl_version
'7.1'
>>> bias.tags
['BIAS']
>>> bias. output
{'BIAS': ['MASTER_BIAS']}
>>> bias.__version__
'2.4.2'

I would suspect that muse_bias is somehow problematic. Does the muse_bias recipe work otherwise? And are you sure that you used the same version for both tests?

[saimn]

Hum weird, this commit looks indeed straightforward, but that's the one breaking thing. If I just checkout the parent commit, and recompile the extension, then it works.

I tried in a fresh environment, and I get the same error, with any recipe. recipe._recipe.frameConfig() returns None. I tried to track this up to cpl->get_recipeconfig and muse_processing_get_recipeconfig but I did not manage to find the issue (self->cpl->get_recipeconfig((cpl_recipe *)self->plugin) returns a NULL pointer). Maybe I should look inside the DRS function, btw I'm using the svn trunk.

[saimn]

Trying to load recipes from different versions of the DRS, that I kept in my ~/.local/lib folder. It works with 2.1.0, but not with 2.3 and 2.5: (with some prints added in CPL_recipe_init)

In [16]: cpl.Recipe.list()[0]
Out[16]: ('muse_scibasic', ['2.1.0', '2.5.0', '2.5.2', '2.3.1', '1.7.0'])

In [17]: recipe = cpl.Recipe('muse_scibasic'); recipe.calib
FOO
BAR
cpl->get_recipeconfig: 0x7f0d4d2c0d80
self->plugin: 0x5639815140f0
cpl_recipe_init: (nil)
Out[17]: {}

In [18]: recipe = cpl.Recipe('muse_scibasic', version='2.5.2'); recipe.calib
FOO
BAR
cpl->get_recipeconfig: 0x7f0d4d2c0d80
self->plugin: 0x563981052c80
cpl_recipe_init: (nil)
Out[18]: {}

In [19]: recipe = cpl.Recipe('muse_scibasic', version='2.3.1'); recipe.calib
FOO
BAR
cpl->get_recipeconfig: 0x7f0d4d2c0d80
self->plugin: 0x5639814256e0
cpl_recipe_init: (nil)
Out[19]: {}

In [20]: recipe = cpl.Recipe('muse_scibasic', version='2.1.0'); recipe.calib
FOO
BAR
cpl->get_recipeconfig: 0x7f0d4d2c0d80
self->plugin: 0x563981090ff0
cpl_recipe_init: 0x5639812561c0
Out[20]: {'MASTER_BIAS': None, 'MASTER_DARK': None, 'MASTER_FLAT': None, 'TRACE_TABLE': None, 'WAVECAL_TABLE': None, 'GEOMETRY_TABLE': None, 'TWILIGHT_CUBE': None, 'BADPIX_TABLE': None, 'NONLINEARITY_GAIN': None}

[saimn]

So after putting printf in muse_processinginfo.c functions, it seems that another muse_processing_get_recipeconfig was called. I removed all my installed versions, reinstalled 2.5.2, and now it works !

[olebole]

It may be somehow bad linking: f.e. that the muse shared libraries are linked to a different CPL library than the recipes themself (however, I don't know how this could happen since they are built at the same time).

In principle, python-cpl should work for different recipe versions linked to different CPL versions, since it executes all CPL functions (like get_recipeconfig()) through a dlopen() for the recipe. If you stumble upon a reproducible environment where this happens, please re-open the bug.