feat: use full minecraft version to get pack_format #472

edayot · 2025-06-07T19:28:51Z

This PR fix #471 by creating a database of minecraft version in a resources folder (like what mecha does for command trees) and using it to get the pack_format.

Disadvantages :

This does add a new thing to update beet on a new minecraft release.
~~This transform the two old classvar to properties, they act the same with an object of that class, but breaks few thing that were using the class itself.~~ fixed

This PR comes with a PR for mecha with new command tree.

rx-dev

mostly approved, makes sense to me

pyproject.toml

rx-dev · 2025-06-17T08:34:08Z

beet/resources/pack_format_registry.py

not sure if the logic for the file should be here, unsure where to put it ..

yes, i didn't want to read the json every time the pack format is accessed

beet/library/base.py

rx-dev · 2025-06-17T08:36:26Z

beet/resources/pack_format_registry.py

+    split_version(x.id): x.resource_pack_version
+    for x in pack_format_registry
+    if x.type == "release"
+}


i guess this file is eager instead of lazy. which is unlike most other files in beet. unsure how i feel about that

i can change it to be lazy, like creating a cached function that return a object with all pack format registry, it would look like this :

class RegistryHolder(BaseModel): pack_format_registry: list[PackFormatRegistry] data_pack_format_registry: dict[Tuple[int, ...], int] resource_pack_format_registry: dict[Tuple[int, ...], int] @cache def get_pack_format_registry() -> RegistryHolder: """Get the pack format registry.""" data = json.loads( files("beet.resources").joinpath(f"pack_format_registry.json").read_text() ) pack_format_registry: list[PackFormatRegistry] = [] for item in data: pack_format_registry.append(PackFormatRegistry.model_validate(item)) data_pack_format_registry = { split_version(x.id): x.data_pack_version for x in pack_format_registry if x.type == "release" } resource_pack_format_registry = { split_version(x.id): x.resource_pack_version for x in pack_format_registry if x.type == "release" } return RegistryHolder( pack_format_registry=pack_format_registry, data_pack_format_registry=data_pack_format_registry, resource_pack_format_registry=resource_pack_format_registry, )

EDIT : copilot suggested this :

""" Pack format registry resource from https://raw.githubusercontent.com/misode/mcmeta/refs/heads/summary/versions/data.json """ __all__ = [ "PackFormatRegistry", "pack_format_registry", "data_pack_format_registry", "resource_pack_format_registry", ] from importlib.resources import files import json from functools import lru_cache from pydantic import BaseModel from beet.core.utils import split_version class PackFormatRegistry(BaseModel): id: str name: str release_target: str | None type: str stable: bool data_version: int protocol_version: int data_pack_version: int resource_pack_version: int build_time: str release_time: str sha1: str @lru_cache(maxsize=1) def pack_format_registry() -> list[PackFormatRegistry]: """Get the pack format registry, loaded lazily.""" data = json.loads( files("beet.resources").joinpath("pack_format_registry.json").read_text() ) return [PackFormatRegistry.model_validate(item) for item in data] @lru_cache(maxsize=1) def data_pack_format_registry() -> dict[tuple[int, ...], int]: """Get the data pack format registry, loaded lazily.""" return { split_version(x.id): x.data_pack_version for x in pack_format_registry() if x.type == "release" } @lru_cache(maxsize=1) def resource_pack_format_registry() -> dict[tuple[int, ...], int]: """Get the resource pack format registry, loaded lazily.""" return { split_version(x.id): x.resource_pack_version for x in pack_format_registry() if x.type == "release" }

i also thinks it makes sense to pull the file remotely and cache it maybe? we do that for vanilla but that's also an optional thing versus this is something that people will use often.

thanks for providing both implementations

But pulling it directly from misode/mcmeta makes it impossible to use beet offline, i like the idea to use misode/mcmeta file but we still needs to add a local registry as a backup strategy

I don't personally like the idea of relying on misode/mcmeta directly during runtime.

misode · 2025-06-18T20:22:38Z

beet/resources/pack_format_registry.json

+  {
+    "id": "1.14",
+    "name": "1.14",
+    "release_target": "1.14",


Beet technically supported down to 1.13 before. I'm not sure if we care about this regression?

I wasn't taking into account this, beet technically support MC 1.6 pack_format 1. Might be needed to hardcode even more values.

misode · 2025-06-18T20:25:06Z

beet/resources/pack_format_registry.json

+  {
+    "id": "1.21.6",
+    "name": "1.21.6",
+    "release_target": null,


This is a pretty large file and has a lot of unused data. Do we want to try to generate this file (in github actions?) and preprocess it to only keep the relevant fields?

Might be a good idea, i was taking this file because it was very convenient.

I was sorting informations i needed in python, but realistically we don't need :

snapshots (as element in the list)

release_target

type

stable

build_time

release_time

sha1

misode · 2025-06-18T20:26:14Z

beet/resources/pack_format_registry.json

+    "id": "25w21a",
+    "name": "25w21a",
+    "release_target": null,
+    "type": "snapshot",


Is it necessary (or even a good idea) to support snapshots? Mecha and other beet features might not necessarily support these versions. Maybe we should just hardcode a list of pack formats for all the release versions?

As discuss in others comments, the plan wasn't to support snapshot.

misode · 2025-06-18T20:30:39Z

beet/resources/pack_format_registry.py

+data_pack_format_registry = {
+    split_version(x.id): x.data_pack_version
+    for x in pack_format_registry
+    if x.type == "release"


Was this tested? Does this work without any other changes? I am guessing the map created here will have tuples with mixed length 2 and 3? Before they were always tuples of length 2.

The return type of split_version was always Tuple[int, ...], so any tuple of any length. Also i tested this version against mecha, bolt and my repos and found no breaking changes.

misode · 2025-06-18T20:32:36Z

tests/snapshots/examples__build_minecraft_1_18__0.data_pack/pack.mcmeta

@@ -1,6 +1,6 @@
 {
  "pack": {
-    "pack_format": 9,
+    "pack_format": 8,


This illustrates that this PR is a breaking change. Specifying minecraft: 1.18 in the config now specifies exactly 1.18, not the last 1.18.x. I know we discussed this a couple months ago in a google docs, but we'll need to be very careful merging this if people rely on this config.

I don't think it's a big deal personally but i account for the issue.

Here's the ggdoc : https://docs.google.com/document/d/1m0niC2I80gMS_yRjQFP9PglhxztAs0b8O5y7XshXp-k/edit?tab=t.0#heading=h.qkfryuqiybl2

edayot

Your last comment reminded me of the existence of this ggdoc, it would be a good idea to implement this in another PR.

edayot · 2025-06-19T16:48:31Z

beet/resources/pack_format_registry.json

+  {
+    "id": "1.21.6",
+    "name": "1.21.6",
+    "release_target": null,


Might be a good idea, i was taking this file because it was very convenient.

I was sorting informations i needed in python, but realistically we don't need :

snapshots (as element in the list)

release_target

type

stable

build_time

release_time

sha1

edayot · 2025-06-19T16:50:49Z

beet/resources/pack_format_registry.json

+    "id": "25w21a",
+    "name": "25w21a",
+    "release_target": null,
+    "type": "snapshot",


As discuss in others comments, the plan wasn't to support snapshot.

edayot · 2025-06-19T16:52:44Z

beet/resources/pack_format_registry.json

+  {
+    "id": "1.14",
+    "name": "1.14",
+    "release_target": "1.14",


I wasn't taking into account this, beet technically support MC 1.6 pack_format 1. Might be needed to hardcode even more values.

edayot · 2025-06-19T16:58:09Z

beet/resources/pack_format_registry.py

+data_pack_format_registry = {
+    split_version(x.id): x.data_pack_version
+    for x in pack_format_registry
+    if x.type == "release"


The return type of split_version was always Tuple[int, ...], so any tuple of any length. Also i tested this version against mecha, bolt and my repos and found no breaking changes.

edayot · 2025-06-19T17:02:15Z

tests/snapshots/examples__build_minecraft_1_18__0.data_pack/pack.mcmeta

@@ -1,6 +1,6 @@
 {
  "pack": {
-    "pack_format": 9,
+    "pack_format": 8,


I don't think it's a big deal personally but i account for the issue.

Here's the ggdoc : https://docs.google.com/document/d/1m0niC2I80gMS_yRjQFP9PglhxztAs0b8O5y7XshXp-k/edit?tab=t.0#heading=h.qkfryuqiybl2

edayot added 3 commits June 7, 2025 19:33

added compatibility for in between minecraft version

a0f79df

black

76f6ad8

black

fd97dcc

edayot marked this pull request as ready for review June 7, 2025 19:40

edayot mentioned this pull request Jun 7, 2025

feat: use full minecraft version to get pack_format #472 mcbeet/mecha#312

Open

edayot changed the title ~~feat: full minecraft version is used to get pack_format~~ feat: use full minecraft version to get pack_format Jun 7, 2025

edayot added 3 commits June 15, 2025 14:21

precompile dict for performance

0433402

rollback classvar

ec29a05

no diff

b404e83

rx-dev requested changes Jun 17, 2025

View reviewed changes

rx-dev reviewed Jun 17, 2025

View reviewed changes

misode self-requested a review June 17, 2025 21:07

edayot added 2 commits June 18, 2025 19:04

Merge remote-tracking branch 'upstream/main' into minecraft_version

08c96dd

1.21.6

b0451af

misode reviewed Jun 18, 2025

View reviewed changes

edayot commented Jun 19, 2025

View reviewed changes

Uh oh!

feat: use full minecraft version to get pack_format #472

Are you sure you want to change the base?

feat: use full minecraft version to get pack_format #472

Uh oh!

Conversation

edayot commented Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rx-dev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edayot Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edayot Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edayot left a comment

Choose a reason for hiding this comment

Uh oh!

edayot Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

edayot commented Jun 7, 2025 •

edited

Loading

edayot Jun 17, 2025 •

edited

Loading

edayot Jun 19, 2025 •

edited

Loading

edayot Jun 19, 2025 •

edited

Loading