houdini_package_manager 2.2.14
GUI package manager for Houdini
Requires Python: <3.12,>=3.11

<p align="center">
  <img width="125" src="https://raw.githubusercontent.com/ariffjeff/houdini-package-manager/main/docs/static/hpm.svg">
</p style = "margin-bottom: 2rem;">

<p align="center">
  <img width="700" src="https://raw.githubusercontent.com/ariffjeff/houdini-package-manager/main/docs/static/hpm_screenshot.png">
</p style = "margin-bottom: 2rem;">

# Houdini Package Manager

[![Release](https://img.shields.io/github/v/release/ariffjeff/houdini-package-manager)](https://img.shields.io/github/v/release/ariffjeff/houdini-package-manager)
[![Build status](https://img.shields.io/github/actions/workflow/status/ariffjeff/houdini-package-manager/main.yml?branch=main)](https://github.com/ariffjeff/houdini-package-manager/actions/workflows/main.yml?query=branch%3Amain)
[![codecov](https://codecov.io/gh/ariffjeff/houdini-package-manager/branch/main/graph/badge.svg)](https://codecov.io/gh/ariffjeff/houdini-package-manager)
[![Commit activity](https://img.shields.io/github/commit-activity/m/ariffjeff/houdini-package-manager)](https://img.shields.io/github/commit-activity/m/ariffjeff/houdini-package-manager)
[![License](https://img.shields.io/github/license/ariffjeff/houdini-package-manager)](https://img.shields.io/github/license/ariffjeff/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>

## 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!


<details>
<summary><h2>Requirements for use</h2></summary>

- Windows (`.exe` distributable)
    - Only tested on Windows 10.
- Houdini 19.5+ (older versions untested)
- A supported version of Houdini must be installed for HPM to launch successfully.
- An internet connection for the package GitHub syncing features.
- In very unlikely situations, a version >= Houdini 20.0.x with [patch(es) pertaining to `hconfig.exe`](https://www.sidefx.com/changelog/?journal=&categories=&body=hconfig&version=&build_min=&build_max=&show_versions=on&show_compatibility=on&items_per_page=).
    - Unfortunately specific user package configurations (`.json` files) cause a program called `hconfig.exe` that ships with Houdini to hang and fail to return valid data, which HPM needs in order to function. I am working with SideFX to fix the issue but in this unlikely scenario HPM might fail to launch or will display that you are missing packages. Make sure you have an up to date version of Houdini with a relevant patch if this applies to you.
</details>

<details>
<summary><h2>How it Works</h2></summary>
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.
1. Gets the raw json package config data (some values might contain variables), typically found in `/packages`.
1. Uses the Houdini environment variables to resolve the package config variables. The data as a whole is also simplified.
1. Creates arbitrary objects from this resolved package config/plugin data.
1. Converts this package/plugin data into a Pyside6 UI with accompanying functionality.
1. 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`.
</details>

<details>
<summary><h2>Building the project yourself</h2></summary>
Note: See `pyproject.toml` to know the python version this project requires for testing and building.

1. Install the [Poetry dependency manager](https://python-poetry.org/docs/#installing-with-the-official-installer) (using either of the CLI commands).
1. Clone [HPM](https://github.com/ariffjeff/houdini-package-manager)
    1. Open a terminal, and `cd` to it.
1. Do `poetry install`
1. 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/`
1. Build the project (for local testing only)
    1. `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)
1. 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.
    1. If you get unexpected behavior, HPM fails to start up, or a crash:
        1. Check the app folder for a .log crash file.
            - Crash log files are currently timestamped/created immediately upon exe run. If HPM is closed normally (not from a crash and not via the debug console) then the log file will be deleted.
        1. Do `make build-exe-log` to make an exe that displays a debug console on run. Run the exe normally (not via a `make` command) to get the console to display. If any errors occur, you can inspect them in the console.
1. Do `make check`
    1. If there are any errors, you must fix them before continuing otherwise GitHub Actions workflows later will fail. If you fixed any errors, run the command again to be sure the checking caught all errors and was able to proceed to subsequent checks.
1. Version bump
    - Automatic version bump: 
        1. Do `poetry version <type>`. Replace `<type>` with either `major`, `minor`, or `patch`. These will also be automatically updated:
            1. `pyproject.toml`
            2. `__version__` in `__init__.py`. (if the Poetry [poetry-bumpversion](https://pypi.org/project/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 (keep reading next steps).
1. Do `make prepare` when you are ready to push a new semantic version
    - **This step checks that your `poetry.lock` file is in sync with `pyproject.toml`. If they are out of sync, the process will stop and instruct you to run `poetry lock`, review and commit the changes, and try again.**
    - This step is important because it does some automatic version management. If you skip this step, future GitHub Actions workflows will fail to create a build and release with the correct version numbers (or fail to trigger at all).
    - This will make a tagged commit which you can simply push if you are confident everything is correct. This will trigger build and release workflows on GitHub.
    - Requirements done automatically:
        - The commit message should just be the version number (e.g. `1.3.2`) for convention.
        - The commit tag should also be the version number (e.g. `1.3.2`). This directly affects the future build and release name.
        - houpm.com's HTML is updated with the new HPM version number.
        - Some other source code is updated with the new HPM version number.
        - Try not to commit anything else with these for simplicity.
1. Push the commit
    - Workflows to build and release will trigger automatically because they are looking for a pushed tag. (It's also possible to push tags without a commit.)
- Pull request to main
    1. Name the pull request the version number (e.g. `1.3.2`) (for simplicity).
    1. Merge to the relevant branch.
1. Edit the generated release
    1. Click `Generate release notes`.
    1. Add any extra descriptive changes for this release.
</details>

<details>
<summary><h2>TODO</h2></summary>

### Priority bugs

- HPM should warn the user if a .json file contains the "path" in-place-of/next to "HOUDINI_PATH" key since "path" is now deprecated by SESI according to their documentation. Or just auto merge "path" value with "HOUDINI_PATH" value (ignore duplicate paths) - (changing the actual json file to remove "path" in favor of "HOUDINI_PATH"). "hpath" technically should work as well but I couldn't get it to work.
- unchecking config button dissappears plugin path, even if actual config json is not set to false

### Features:

- Be able to create a default plugin folder structure from a template from HPM. (containing /otls, /scripts, /toolbar, etc.)
- Be able to migrate scripts and otls to other Houdini versions.
- allow user to configure a plugin to not apply to certain Houdini version. i.e. a plugin is obsolete in a newer Houdini version because SideFX adds a node that has the same/better functionality.
- node tree view editing of package/script/otl dependencies for each houdini version
- warning dialog for about to overwrite package config when creating a package
- allow HPM to find loose otls and scripts that aren't in a folder
- easy editing of houdini env vars
- pref pane to disable auto update
- refresh package tables when new packages created
- ability to delete package table items
- give option to use existing .json package config created by plugin dev instead of using default template
- the other meta header data
- sort table by rows
- status log history (executed actions only)
- donations link
- ability to easily set most of the top-level variables ("load_package_once", etc.)
- See what versions of houdini a package is in from a glance.
- button that finds new installs of houdini (it might already do this? or just restart the app)
- packages with houdini patch version specifications should be represented visually somehow
- proper svg color changing: https://stackoverflow.com/questions/33512884/pyside-change-color-or-opacity-of-svg-in-qicon
- create tables scripts and OTLs not directly a part of any package
- search bar for packages - isolates row in table (for when you have a lot of packages)

### Bugs
- class `PackageConfig`:
    - search paths for plugin HDAs (\otls)
- `_get_houdini_paths()` does not account for linux/macos
- `packages_table.py`
    - utilize `_main.json` to locate loose HDAs and scripts that aren't actual plugin packages
</details>