compas icon indicating copy to clipboard operation
compas copied to clipboard

FeatureRequest: use __str__ of type instead of type in run/import-time registration of object

Open tkmmark opened this issue 3 years ago • 4 comments

for artists, and rhino objects... In order to make it more possible to use the current version of unload_modules() when working with a collection of modules and scripts (such as when one is developing plugin). since the equivalency of class/types will be gone for the same classes (even if no changes were made to the underlying classes) after invoking unload_modules().

tkmmark avatar Dec 01 '20 17:12 tkmmark

not sure where exactly you mean.. could you please add an example of this? is it related to the scene stuff?

gonzalocasas avatar Dec 01 '20 17:12 gonzalocasas

Ah yes, I meant situations like this:

image

tkmmark avatar Dec 07 '20 11:12 tkmmark

I was suggesting that we use some string based representation for building the type-to-object dict (e.g. str of type, or dtype). I realise this already sounds rather hacky, but I was thinking about this because of issues I was having with unload_module, which I was using hoping to access updated code done on a datastructure module, so I do not have to restart Rhino and reinitialise everything. But it is rather tricky to get rid of all the old modules, or get all the reimported modules to be in sync (between GH and IronPython, between IronPython and RunPythonScript) and the type for the same datastructure will not be equivalent as a result.

tkmmark avatar Dec 07 '20 11:12 tkmmark

I guess the best would be to state your root problem in the feature request, instead of a tentative implementation, otherwise, we might end up implementing a feature that does not solve your root problem in an optimal way.

Regarding what I understand so far as the root problem, it seems to be a matter of doing the right cleanup and potentially re-registration, rather than changing the internal representation of the registry. If I get it right, you are developing a plugin, and you want to improve your development workflow because certain things force you to reset the script engine to properly reload after changes. On a superficial level, I would say there's never the need to reset script engine for dev workflow, unload_modules (used with the right prefix to make sure everything we want is really unloaded) and probably a call to register afterwards sound like they could restore state to a clean situation.

However, I might be missing details about your workflow that make this more complicated. Could you please elaborate further on the workflow or attach a concrete example to replicate? (or a video?)

gonzalocasas avatar Dec 09 '20 23:12 gonzalocasas