search

sardana-org / sardana

Moved to GitLab: https://gitlab.com/sardana-org/sardana
39 stars 51 forks source link

Unable to run macro: PyDs_PythonError UnknownMacro: Unknown macro macro1 (SF#401) #246

Open sf-migrator-bot opened 8 years ago

sf-migrator-bot commented 8 years ago

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 instead of .

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

Reported by: jkotan ( http://sf.net/u/jkotan )

Original Ticket: sardana/tickets/401

sf-migrator-bot commented 8 years ago

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

Original comment by: teresanunez (http://sf.net/u/tere29)

sf-migrator-bot commented 8 years ago

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

Original comment by: jkotan (http://sf.net/u/jkotan)

teresanunez commented 3 years ago

I think this issue can be closed, since some work was already done related to it.

reszelaz commented 3 years ago

Thanks @teresanunez for the review of this issue. I propose that we wait for SEP19 until closing all the 20 issues related to the plugin system. The SEP19 objective is to address all of them.