Custom node can't be locally published

Hi all,

I’m trying to locally publish a custom node. This node is based on other custom nodes from downloaded packages. Dynamo won’t let me publish them and returns this error :

which means :
“Some nodes are included inside a package. Please only use nodes that are not included inside a package”

Is it not possible tu use nested nodes for a custom node ?

These types of dependencies are doable, but the nodes need to be copied out of the package first. This is to help navigate dependency issues.

OK.
In what file should I copy the nodes that I need ? We’re talking about copy, not cut, right ?
Right now, my packages are in this file :

It’d be cut of the entire package, which can be difficult to pull off. As I recall this is set up because you likely don’t want to do this without a REALLY good reason, as it can cause other issues down the line which I can’t remember. It’s been a long time since I’ve had to deal with this (my custom nodes are all entirely my own now), so we may want to seek input from @Michael_Kirschner2 or others who have more history with the intension here.

So you’re saying that an alternative option is to enter the package nodes, copy-paste the Dynamo core nodes into my own custom node, and it works the same ? It’s a shame that you can’t nest nodes. It would be cleaner I think.

Hi,

I’m facing the same issue here. I’m wondering what’s the best way to deal with custom nodes dependent on external packages. I’m trying to publish (locally) a package of custom nodes. When nested custom nodes come from the same package, publishing is working fine. But now I’m trying to publish a new node which contains “Group curve” from archilab package.

It seems possible to combine these external nodes into custom nodes. BVN package for example has some nested nodes referencing other packages. But it doesn’t work for my own package.

For now, if I don’t find another solution, I might just publish my “own” version of Group curves, as it is a local publish. But it bugs me and it opens the broader question of intellectual property especially if published online. What would be the best practice to follow regarding this question? :thinking:

hmm -

I think this only occurs with local publish behavior, honestly I am not sure why, I think there is a good discussion in the linked pr - I believe if publishing online the package will have a dependency marked, but I guess the idea was when publishing locally that a package was to be made easy to share as a single working unit so this check is done.

Thanks Michael, at the moment my own custom package is published in a separate root folder than the rest of my library. I might try again later by publishing in the same root folder and see if it fixes it. Will keep you posted about that.
Cheers!

I’ve read through a couple of theses posts and am still having issues with this error about nodes from other packages used in Custom Nodes.

To verify: are you saying you need to copy the specific dyf that are used in the custom nodes in the package to be published into the dyf folder in that packages dyf folder?

I tried this and the package becomes unresponsive in the package manager. My expectation is that this is because the contents of the folder and the json data no longer match.

I tried adding those files directly through the package manager interface and i get the same error.
image

i was able to publish my package in R2022 to prior to R2022.1.2. I don’t understand what has changed that i’m suddenly running into these issues.

I do not recommend publishing packages which rely on other packages custom nodes, as it’s quite problematic. You get duplicate files, run the risk of not complying with the license in use by a given package, have a required dependancy to update which will rarely if ever align to the larger environment, and all sorts of other issues.

That said, the copy out was what worked for me before. However if you want to run this in more depth you’ll need to post your custom nodes in question to a new topic, as I can’t reproduce otherwise.

hmm. ok. I’ll explore more reliable methods.

I frequently want to use custom nodes as functions within a script, especially to help deal with ‘straight to cross laced’ issues and making the list lacing less complicated. For example, if i have a procedure that takes inputs a = [A0 … An] and b=[B0 … Bn] where Ai and Bi are sublists, and we want to use the cross lacing of Ai x Bi, using cross lacing on a node for a x b doesn’t give that result.
image

but it seems like dynamo wants custom nodes to be more like missing building blocks/api access than complete subroutines.

I’ve tried to start just writing designscript functions instead, and this seems to help with readability, but you can’t always include a node from some packages as part of a designscript function.

1 Like

This is correct. It’s technical debt and it sucks. Generally speaking if you have an external dependancy (what those packages are) you have a few options:

  1. Consume the dependancy, and publish it with your code. This has licensing implications (ie: similar to how Dynamo’s “about” mentions Avalon Edit) to account for, and means you need to test your software (what Dynamo graphs and custom nodes are) against not just the environment it’s going to run in (ie: Dynamo 2.3 to 2.13; Revit 2020 to 2023) but also against the permutations of the dependancy in those environments. An update to the dependancy could break your custom node after all.
  2. Note the dependancy and let others put things in place. The built in package tools prevent this, as it’s a nightmare for end users; You could hack around that, but it’d be a lot of effort.
  3. Write new code to circumvent the need for dependancy. This is often the case when options 1 and 2 become unsuitable. Be sure to do so in a way which complies with the licensing (as noted in #1) for production and distribution purposes.