#401 Unable to run macro: PyDs_PythonError UnknownMacro: Unknown macro macro1

[Jan Kotanski]

Hi,

I get collision of two different sets of macros when they are defined in two different packages but in the module with the same file name.
In this situation only one set of macros works (random one),
other gives an error:

 Unable to run macro: PyDs_PythonError UnknownMacro: Unknown macro macro1

To reproduce it one can create in spock

edmac macro1 /home/jkotan/testmacro/package1/macros.py

macro1

edmac macro2 /home/jkotan/testmacro/package2/macros.py

macro2

macro1

where package1 and package2 are two different packages with init.py files.
In this case the second call shows the error.

The reason for this behavior is breaking python rules by macromanager and sardanamanager when they use sys.modules. Sardana put to the sys.modules dictionary a module with a key containing only <module name=""> instead of <packages>.<module_name>

One solution could be to add _findModuleName function to macromanager
which finds module name with its packages and use in in sardanamanager.

An example for solution could be find in

git.code.sf.net/u/cmft/sardana-GenericSoftware/feature-380

in the commit

 b3901533a8cbb5229c719931b503e59aed41b3f7

where the solution is implemented for recordermanager.

A similar problem occurs for controllers.

This problem can be annoying when a user whats to use macros with to different sources and by accident they are stored in modules with the same module file name but in different packages.

Cheers,
Jan

[Teresa Nunez]

Hi,
I think one has to be careful there ... do we want to have macrolibs with the
same name?, we could want to change a macro library file from one directory to
another one and the system can not know that this library should replace the
other one and not be added as a new one (one could have made a rename of
macros, or added new ones ... what should the system do?, add the new ones
and keep the olds because I change the place of the file?). I think it could be messy
if we (even worst, the users) have to distinguish the macrolibs also taking into
account the module to which they belong. Recorders and Controllers are something
different from the 'use of the users' point of view.
Well, it is only my opinion, but I think one should avoid adding complications to the
users.

                                                   Regards,
                                                                        Teresa

[Jan Kotanski]

Hi,

Yes. I agree that comparing to recorders and controllers with macros we should be careful.

However, in Python modules are labelled by the packages (directories with init.py file) to which they belong to. So, if we have two modules with the same file name but placed in different packages they have to be treated separately (1).

The opposite situation is when you put modules in simple directories (without init.py files) then Sardana has to treat them as the same file and resolve the ambiguity (2).

In the first case (1) macrolib name related to module name should contain also its package name (i.e. long name). One could provide mechanics what user could use its short name (only with the module name) and in the case of ambiguitythe longer one.
In the second case (2) the long name would be equal to short name (only with the module name). So if some facility wants to use only short name it can install modules in directories without init.py files. (This should behave as the current implementation, except some mess caused by non-ordered dictionaries)

This proposition aims to have common module mechanics for macros, controllers and recorders which does not violate python rules.

For controllers and recorders, for which users do not have right to touch, and are installed from separate system (e.g. debian) packages the solution (2) is more natural. In this case we could avoid the situation where we have two different controllers (or recorders) coming from two different sources in two different packages accidentally with the the same module file name.

What do you think about it?

Cheers,
Jan