Open sf-migrator-bot opened 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)
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)
I think this issue can be closed, since some work was already done related to it.
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.
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:
To reproduce it one can create in spock
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
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