Table of contents > Distributing your nodes
This chapter explores how to distribute/share your nodes based on whether you want them to be used as local node packs or installed node packs. Both methods have their advantages and disadvantages.
In summary, you can either:
Neither method is better than the other. Both have their advantages and disadvantages. They can also be used in combination, each in a specific stage of the node pack's life. We'll explain all of this in the rest of the chapter.
As explained before, Nodezator manages nodes by having them organized within categories inside a folder we call a node pack. With such folder structure and the scripts contained within, the node pack can already be distributed as-is by whichever medium you want, uploading to the web and sharing a download link, emailing to friends or co-workers, etc.
This is the simplest way of using/distributing node packs. It is straightforward and requires no understanding of packaging in Python, which makes it accessible to newcomers. It is also great for experimentation for people with all levels of proficiency in Python. In other words, you just create the folders, create your scripts and they can be loaded and executed right away on Nodezator. You don't need to know packaging in Python nor bother dealing with the extra work required.
If you already have a node pack you created and want to distribute them this way, you can already upload it to any service on the web where people can download it. I recommend GitHub, since it provides not only storage for your code but also source control via the underlying version control system called git. If you are not familiar with how GitHub or git works, you may use a simpler storage service like Google Drive or Dropbox as well. Then, just share the link so people can download you node pack.
I recommend this kind of usage for people beginning with Python, specially those with no experience in packaging. However, any Python developer should use it as well, really, since it has exclusive advantages.
Here are examples of local node packs I uploaded to GitHub:
You can download those repositories right away and load their nodes in your .ndz file by following the instructions in the chapter about loading nodes.
The only minor hassle users of local node packs face is that, when they open a nodezator file from an external source for the first time, if that file references local node packs, they'd need to fix the path to point to the local copies of that node packs. This is easy and quick and only has to be done once.
Local node packs should really be used by everyone when appropriate, regardless of whether they are a seasoned Python developer or not. For instance, even if you are used to configuring and uploading Python packages, if you are just experimenting with creating a new node pack, why bother dealing with all the extra steps needed to upload your node pack to PyPI only to test it?
Once the code defining your nodes is ready, you can use it in Nodezator as-is, as a local node pack. Just load the node pack right away and start testing/using/improving it. This is an advantage of the local node packs.
The alternative to using/distributing node packs as local node packs is making then installable via pip, that is, distributing them as installed (or installable) node packs. This alternative way requires a bit more knowledge about configuring, packaging and uploading Python packages to PyPI (the Python service to store and distribute Python packages).
This is so because in order for them to be installable, you are required to turn your node pack into a Python package and upload it to PyPI. This not only comes with the extra work of configuring it, but there's also the tacit expectation (at least by some people) that you'll be properly maintaining your Python package.
Once your node pack is uploaded to PyPI, you don't need to worry about distributing your node pack source yourself. Your users just need to install your node pack via pip install [name_of_your_nodepack] since you turned it into a Python package.
The advantage of distributing your node pack as an installable one is that .ndz files you create and share can be opened by others in their computers without them having to fix any path the first time. This is so because Nodezator can find the node pack automatically using the name of the package. That is, since the node pack is now a Python package, users of your node pack just need to install it and Nodezator can import it right away using its name.
Using/distributing a node pack by making it installable via pip doesn't require any changes in your node pack source per se, but you'll have to create a new folder wherein to put your node pack and extra files which represent metadata about the Python package which your node pack will become. You'll also need to include some empty __init__.py files into your node pack (if they don't exist already) just to assist third-party tools in the packaging process.
The last section of this chapter presents a link to an installable node pack that serves both as an example and as a template to help you package your own installable node packs.
Here's a table summarizing how the methods differ:
| Aspect | Local node packs | Installed node packs |
|---|---|---|
| Creation | create folder and scripts divided into categories | create folder and scripts divided into categories |
| What can be achieved | allows any level of work, from simple to advanced | allows any level of work, from simple to advanced |
| Package management | doesn't need package management | requires author to package node pack and upload to PyPI |
| Node pack selection | need location of node pack | need name of node pack |
Note that both methods are the same regarding how the node packs are created and what can be achieved with them. Both are created and organized in the same way. You can also use any of the methods regardless of what you want to achieve, be it simple or complex stuff.
Under the hood, Nodezator only cares about whether a node pack is local or installed when loading them. Once the node packs are loaded they are all treated the same way.
You don't need to choose ony kind of distribution over another. It may actually be better to use both method, one in each specific stage of the node pack's life.
At the beginning, when you are populating your node pack, creating and testing new nodes, you can use it as a local node pack. Then, once you are satisfied with your results you can worry about packaging your node pack and publishing it as a installable node pack. As explained before, once loaded, nodezator doesn't make a distinction between local or installed node packs.
This is so because .ndz files store node layout data based on the names of the node packs, their categories and node scripts. This means, for instance, that if you have a local node pack called "mypack", a .ndz file containing nodes from such pack and you want to publish your pack as an installed one, you can do so easily:
And that's it. As long as the name of the node packs are the same this will work right away.
There's a template demonstrating how to package and publish a node pack to PyPI in this online repository.
Beware that this template does not attempt to teach you the best way or configuration for your package. It just presents one possible and relatively straightforward way of packaging your node pack. Teaching about packaging in Python and the many options available is outside the scope of our project.
Even so, we always welcome questions and people seeking help, so if you have any trouble just reach us on github discussions for Nodezator or the Indie Python discord server.