Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store generated UUIDs in a lock file and don't hide them #42

Open
phoenixr-codes opened this issue Nov 12, 2024 · 0 comments
Open

Store generated UUIDs in a lock file and don't hide them #42

phoenixr-codes opened this issue Nov 12, 2024 · 0 comments
Labels
enhancement New feature or request priority - medium Issues with medium priority

Comments

@phoenixr-codes
Copy link
Contributor

UUIDs should always be the same for the add-on. So if the project is for example pulled and built by someone else, it is important that they have the same UUIDs as the BP may make use of a custom manifest which has the RP's UUID as a dependency (or an external add-on not directly related to the project).

It would make sense to introduce a allay.lock file that stores this information. It could look like this:

# This file is @generated and managed by Allay
# Do not edit this file manually!

[uuid.bp]
header = "<uuid>"
modules = { data = "<uuid>", script = "<uuid>" }

[uuid.rp]
header = "<uuid>"
modules = { resource = "<uuid>" }

[uuid.sp]
header = "<uuid>"
modules = { skin_pack = "<uuid>" }

[uuid.wt]
header = "<uuid>"
modules = { world_template = "<uuid>" }

On top of that, all UUIDs should be generated on demand. The allay uuid subcommand can gray out UUIDs that are (probably) not used.

@phoenixr-codes phoenixr-codes added enhancement New feature or request priority - medium Issues with medium priority labels Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority - medium Issues with medium priority
Projects
None yet
Development

No branches or pull requests

1 participant