Inconsistent category folder handling

[gregismotion]

Inconsistent category folder handling

[KennedyRichard]

Mr. Vári,

There's a chance I'm mistaken, but taking into consideration what you described, I suspect you might actually be confused about how Nodezator loads node packs.

Each node pack directory must contain only folders representing categories and each category folder must only contain folders representing node scripts. The prompt shown in the image indicates that Nodezator is assuming the templates folder is a category folder because it is inside the lazycanvas node pack folder.

In other words, only node script folders are allowed to have content other than the script defining the node.

This is intentional design with the purpose of making the node scripts as modular and free of side-effects as possible, in alignment with the many paradigms that Nodezator take inspiration from, like functional, dataflow, flow-based and component-based programming. Since you are new to Nodezator and may not be familiar with these paradigms or just used to how other node editors deal with this, it might be hard at first to see the advantages of doing things this way, and I'd not blame you for that if it was the case. However, I argue that node-based programming is much more effective when adopt such principles of avoiding side-effects and keeping the node scripts as modular as possible.

This doesn't hinder/harm nor makes any kind of workflow impossible, because there are other ways to share resources between your node scripts without having to include them as folders in your node pack folder or the categories folder within it. I'll present the ones that come to mind.

If you have code that you want to share between different node scripts, then you must put such code in a library and make that library available somewhere your Python interpreter can see, so that such code can be imported from your node scripts. For instance, you can put your module/package in your site-packages folder, that you can find with:

from site import getsitepackages
getsitepackages()

If the resource you want to share is not code (files, images, databases, etc.), you can also use the solution presented earlier, that is, put them inside the module/packages to be imported. There are 02 more alternatives to this though.

First, you could put them in a known central place in your system and reference them in your node script folders by their location. For instance, if you have an image you can put it on the pictures folder in your home folder and then any node script that may want to use that image can reference it like this, for instance:

from pathlib import Path
path_to_image = Path.home() / 'pictures' / 'my_image.png'

Second, you can put that resource in one of your node scripts and use it to access that resource instead. For instance, if you have a database that you want to access, you can use a node to do so, like in this pseudocode:

from pathlib import Path
from dbprocessing import get_db_obj

path_to_db = Path(__file__).parent / 'my_db.db' # this is inside this node script
MY_DB = get_db_obj(path_to_db)

def get_reference_to_db():
    return MY_DB

main_callable = get_reference_to_db

Then you can instantiate this node in your graphs and grab the database object from its output to send to other nodes.

There may be other Python-related ways to share resources like the ones I described, but they are the ones that came to mind for now. Again, not allowing nodes to share resources directly is an intentional design decision that is adopted in many programming paradigms and results in systems that are more easy to maintain, operate and extend.

Nonetheless, all feedback and even constructive criticism is always welcome, so feel free to share your mind on this.

Also, please, regardless of your opinion on this, let me know whether I was able to explain the cause of your problem accurately or you still think the problem may actually be something else altogether.

[gregismotion]

I totally see the approach here: and this is actually more sustainable in the long-run.

My first idea was to allow my libraries to function as node-packs themselves, but I might seperate some of them with an "_ndz" suffix. (so "xyz" as a library and "xyz_ndx" as a node-pack that depends on said library.)