I ask people, "Can you share your package json?", to which they say one of the following:

• "I copied it into my houdini20.5 folder." (Oh god no)
• "I put the path in houdini.env" (It works but it can be better)
• "Sure, here's the json." (Smashing)

Let's first take a look at the goal, the process, and how we can achieve it as simply as possible.

The Goal

To have multiple packages and plugins installed, without causing errors, and being able to easily control what's enabled, if needed.

How does Houdini load these files?

In short, Houdini loads files from the HOUDINI_PATH environment variable. The reason people add to houdini.env, is that its the simple way to do that.

How does it make it work?

The simple of it, is there a certain structure in the houdini20.5 (or other versions) folder, and that can be matched in any other location, as long as the structure resolves itself nicely.

If its easier to think of it in text: Folder A has a folder called "images", folder B has a folder also called "images". These 2 folders can be merged together just fine, where the contents of "images" are the files inside images in both directories. This is what Houdini does for all of the HOUDINI_PATH locations, and is able to see all the files and folders in there.

This also works for folders that don't exist in both places:

Package JSON

This is where the package folder comes in. Houdini will read all of the json files in the `packages directory, and add those paths to the environment.

Knowing what we learnt above, we can understand that this package file for LV Tools will 2 two things:

{
	"env": [
		{
			"LV": "D:\\05_Houdini Packages\\LV Tools"
		}
	],
	"path": "$LV"
}

You can see we place the LV path under the env bit. This simple creates a variable we can use in Houdini, similar to how you have $HIP and $JOB. Then, we use path: $LV to say, "Hey, add the $LV path, to our HOUDINI_PATH"".

Not too complicated?

Additional waffling

Here’s the deal: copying files directly into the Houdini install or preferences directory makes it incredibly difficult to manage. You can’t easily toggle plugins on or off, you can’t share setups cleanly, and maintaining version control becomes a nightmare. It’s a brittle system that doesn’t scale well—especially if you work in a team or switch between Houdini versions.

That’s where package files come in. These are JSON-based configuration files that let you define exactly how Houdini should load tools, plugins, and custom scripts—without polluting its core directories.

The key piece of this puzzle is Houdini’s HOUDINI_PATH environment variable. This variable tells Houdini where to look for its folder structure. When you set up a package file, you can add custom paths to HOUDINI_PATH, and Houdini will treat those paths as if they are part of its standard structure.

In practice, this means you can:

• Keep your tools in neatly organized folders anywhere on your system or network
• Add or remove packages by simply toggling one line in a .json file
• Maintain multiple versions of plugins with ease
• Share consistent setups across teams or pipelines

You go on GitHub, and someone has very graciously packaged all their tools up into a nice repo, and you download it and put it somewhere reasonable (let's say Z:/Packages/LV_Tools). Now you can simply download the folder, and use what we learned above to add the path to HOUDINI_PATH