Working with / accessing shared modules

General TouchDesigner Discussion
1

Hello,

please may I ask how do you approach working with foo_module from different locations in following situation?

/project
├── foo
    ├── foo_module
    ├── bar
        ├── bar_module
        ├── baz

Lets assume foo_module have some enums, constants, functions that should be used from all inner component modules / parameters (lets say that in this scenario it doesn’t make much sense to make them part of an extension, but rather a shared module).

This approach is nicely described by @tekt in his article

  1. Start by putting things within the specific component where they’re needed, perhaps as methods of an extension class that’s defined inside a particular component.
  2. If you have a specific need to use it somewhere else, then pull it up to a level that contains both of those things. That might mean creating a shared module that’s specific to some portion of the project that contains the components that need it, or it might mean a project-wide shared module.

For example when in bar_module, one could work with foo_module like this, but I am not sure if there isn’t some better way of doing so?

foo_module = mod('../foo_module')
foo_module = mod(parent.Foo.op('foo_module'))

foo_module.foo()

Also when working with parameter expressions in baz, I am guessing one would have to use similar syntax:

mod('../../foo_module').CONST
mod(parent.Foo.op('foo_module')).CONST

My question is whether there is some better approach to this situation, or whether there is some way to make the expressions shorter / more readable? I know DAT modules can’t be organized to packages based on wiki:

Also note that DAT modules cannot be organized into packages as regular file system based python modules can be.

But I was wondering whether there might be a way to access foo_module using something like this:

import foo.foo_module

foo.foo_module.foo()
foo.foo_module.CONST

Thanks :slight_smile:

Edit: Related to this thread

2

Ah, I have completely forgotten about local modules! So then it would look like this.

/project
├── foo
    ├── local
        ├── modules
            ├──foo_module
    ├── bar
        ├── bar_module
        ├── baz

Then accessing foo_module looks much nicer:

foo_module = mod.foo_module
foo_module.foo()

Now I have noticed import also works, which is great:

import foo_module
foo_module.foo()

I feel like this is a good way to go. Or is there even better way of doing so? :slight_smile:

1 Like
3

You figured out the nice way. That said, extensions are often better and cleaner. Note that ext.MyProjectExt will keep searching upward until it finds an extension with that class name. This means you can access parent extensions very easily.

4

Thanks for info @Ivan, I am glad I am on the right track :slight_smile:
Yes, I am trying to use extensions as much as I can, but sometimes (not often) I feel like some stuff is better located directly in modules - but maybe my judgement is wrong there.

For example I felt like something like following enums and constants should go into a module (as placing them into component extension didn’t make much sense to me). But that is just an example to illustrate why I was trying to go that way.

class ConnectionStatus(Enum):
	PINGED = -1
	DISCONNECTED = 0
	CONNECTED = 1
	PENDING = 2

class BatteryStatus(Enum):
	NOTPRESENT = 0
	DISCHARGING = 1
	IDLE = 2
	CHARGING = 3

COLORS = {
    'bg.layer0' = tdu.Color(0.2, 0.2, 0.2, 1.0),
    'bg.layer1' = tdu.Color(0.3, 0.3, 0.3, 1.0),
    ...
}
5

Whatever works best for you!

1 Like