QPM 2 PoC

[Fernthedev]

QPM 2

Notable changes

Shared QPM JSON

The Shared QPM JSON is now exclusively a locked dependency mechanism. It is no longer used to store information for consumers of the package.

Furthermore, it will no longer be used to retrieve information that is stored in qpm2.json. This means you no longer have to restore to see changes applied.

Triplets

QPM 2 introduces triplets, a notion where a package can be customized into different flavors so to speak. Some examples of this are debug, static or headerOnly but also curl or ureq flavor of a package. Ideally they allow a package author to offer various versions of a package to consumers. An example of this would be beatsaber-hook offering unity2019,unity2021,unity2022,unity6 versions of itself.

Additionally, every package must contain a default triplet, where every other triplet inherits the triplet's values. Arrays and objects are also merged.

Environment values

Environment is a dictionary of keys and values where dependencies can offer information for consumers. Examples of this would be bs-cordl offering game id and version for usage in scripts or qmod.

Examples of this are:

• ${QPM_PACKAGE_ID}
• ${QPM_PACKAGE_VERSION}
• ${QPM_ACTIVE_TRIPLET}
• ${QPM_QMOD_GAME_ID}
• ${QPM_QMOD_GAME_VERSION}

Environment variables are all prefixed QPM to ensure they don't abuse the existing environment variables maliciously.

For example, QMOD_GAME_ID in a qpm.json would be used as QPM_QMOD_GAME_ID.

QPKG

Packages would no longer use Git or zips for installation. Rather, they would use qpkg, a renamed zip file that contains info of its headers, binaries and package. This streamlines lots of headaches related to QPM using git such as the git branching and versioning while also allowing one to download QPKGs from URLs (ideally for testing without releasing).

cargo install would now require a path or URL to install a QPKG from.

Building with triplets in mind

As triplets can each have their own set of dependencies, qmod and configuration, it changes the traditional way we looked at building packages. A QPKG must be able to store binaries of every triplet possible.

Therefore, qpm build now exists and will do the following to build your package:

• Iterate over every triplet
  • Restore dependencies
  • Run qpm s build
  • Run qpm qmod zip if necessary
  • Copy the binaries to extern/build/{triplet}

Publishing QPKG

Since there is no longer Git involved in the publish process, it becomes much simpler. The hardest part is configuring the qmod links and the QPKG itself with the necessary configuration. For making the QPKG, QPM now offers qpm qpkg which will grab every binary in extern/build/{triplet} and the shared headers and configure the QPKG.

Once that is done, one must store the QPKG somewhere online and offer a direct download link to the QPKG. With that done, running qpm publish {qpkg_url} will publish your package to qpackages.com, allowing restore.

Compatibility with QPM 1

There will be no backwards compatibility with QPM 1. While many commands remain the same, the fundamental changes make it very hard to consider backwards compatibility. Therefore, a new registry and config directory is used to allow QPM 1 and QPM 2 to co-exist.

This also means that to allow this, many files related to qpm are now referred to as qpm2 e.g qpm2.json, qpm2.shared.json etc. to allow a package to continue serving QPM 1 users for whatever need be.

Migration

A migration Deno script is offered to allow easier migration to QPM 2. It assumes that the QPM 1 package only contains one triplet, which would be the default triplet.

deno run -R -W https://raw.githubusercontent.com/QuestPackageManager/QPM.CLI/refs/heads/qpm2/migrate.ts