Houdini Package Manager

A comprehensive GUI package manager for Houdini. Manage all your plugins and create new packages with ease.

• Download the application: https://houpm.com
• Github repository: https://github.com/ariffjeff/houdini-package-manager
• PyPI repository: https://pypi.org/project/houdini-package-manager

How it Works

HPM is a Python application that basically grabs your plugins' package config files and converts them into a nice UI with a bunch of useful functionality.

1. On a high level, HPM does this for all installed versions of Houdini it finds upon startup:

1. Gets Houdini's environment variable key value pairs.
2. Gets the raw json package config data (some values might contain variables), typically found in /packages.
3. Uses the Houdini environment variables to resolve the package config variables. The data as a whole is also simplified.
4. Creates arbitrary objects from this resolved package config/plugin data.
5. Converts this package/plugin data into a Pyside6 UI with accompanying functionality.
6. This is all then built into an executable with Pyinstaller.

2. Creating package configs for new plugins:

• You can create new package configs for plugins you have downloaded to quickly get them into Houdini hassle free.
• HPM takes the plugin folder path, HDA, or script you provide it and simply creates a new package config from a template, and puts it in /packages.

Install

1. Download the latest version from https://houpm.com
2. Unzip and store the folder anywhere you want.
3. Create a shortcut of the Houdini_Package_Manager-x.y.z.exe file from the folder.
4. Now you can run HPM from the shortcut, that's all there is to it!

Building the project yourself

Note: This project was primarily tested with Python 3.9.10.

1. Install the Poetry dependency manager.
2. Clone HPM
   1. Open a terminal, and cd to it.
3. Do poetry install
4. Make your code changes and commit them
   • If you're adding other files/images/vectors/etc., put them somewhere appropriate in houdini_package_manager/resources/
5. Version bump (optional)
   • Automatic version bump:
     1. Do poetry version minor. Use major or patch in place of minor if appropriate. These will automatically be updated:
        1. pyproject.toml
        2. __version__ in __init__.py. (if the Poetry poetry-bumpversion plugin is installed)
        3. The relevant HTML in houpm.com. (auto updated later by make prepare)
        4. The final executable and .zip file/folder names. (auto updated later by make prepare)
   • Manual version bump:
     1. Do poetry version 1.2.3
   • Commit the version bump later along with a new build (keep reading next steps).
6. Do make prepare
   • This does all the final build management automatically by running a bunch of other commands.
   • Review these make commands only if you need to use them individually...
   1. make test runs the project pytests. Skip them with make prepare TEST=0
   2. make build-exe builds the project. It will appear in dist/
      • resources/ is copied to the build folder automatically so you don't have to worry about it.
      • The build folder and .exe name is determined by the version number set by the result of poetry version ... (referenced in the Makefile)
   3. make zip zips the build in dist/
   4. make dist-move creates a copy of the dist build in the HouPM website dist_hpm folder.
   5. make update-houpm updates HPM version html in houpm website.
7. Run/test the build (sanity check)
   1. Run the build
      • Different methods:
        1. Go to dist/, find the .exe and run it.
        2. Or do make run-exe.
           • Be aware this doesn't run it directly in the folder its in, which can lead to the issue of relative file paths not being able to find the files they're targetting if the paths have been set improperly... i.e. images failing to load. Make sure you set file paths with utils.epath() which automatically handles relative paths correctly for both the dev and build environment.
   2. If you get unexpected behavior or a crash:
      1. Check the app folder for a .log crash file.
         • Crash log files currently are timestamped/created immediately upon exe run. If HPM is closed (not from a crash and not via the debug console) then the log file will be deleted.
      2. Do make build-exe-log to make an exe that displays a debug console on run which you can inspect. If any errors occur you'll be able to see them there.
8. Commit
   • Commit both the version bump (mentioned before) and the new build .zip together.
   • The commit message should just be the version number (e.g. 1.3.2) for convention.
   • Try not to commit anything else with these for simplicity.
9. Tag the commit
   • The tag name should be the version number (e.g. 1.3.2) for convention.
   • You can do this by right clicking the commit if you're using a GUI like GitHub Desktop.
10. Push and pull request
    1. Name the pull request the version number (e.g. 1.3.2).
    2. Merge to the relevant branch.
    • Hopefully you haven't pushed directly to main.
11. Create a new release
    1. On GitHub, go to Releases.
    2. Select the tag version number (e.g. 1.3.2) from the dropdown.
    3. Name the title the same version number.
    4. Click Generate release notes.
    5. Add any extra descriptive changes for this release.
    6. Click publish.
    • PyPI will automatically be updated with the new HPM version via a GitHub action.