Question on how to handle trmnlp IDs

[depau]

Hi!

By reading the source code I eventually figured out it is possible to use trmnlp by overriding the server manually in the config:

~/.config/trmnlp/config.yml

base_url: https://trmnl.my.host
api_key: XYZ

By also reading the source code I eventually figured out it is possible to use trmnlp push/pull as long as a trmnlp ID is defined both remotely and locally.

I have a few questions about that:

• Are these IDs supposed to be universally unique? If I understand correctly, when creating a recipe on usetrmnl.com an ID gets assigned and you can stick with that. However I am not using it and I do not intend to use it, so how should I pick my ID? It would have been nice if UUIDs were used, since by design they are Universally Unique.
• What should we do with recipes we publish to https://github.com/bnussbau/trmnl-recipe-catalog? For the one I submitted yesterday I simply removed the id from settings.yml. However that's very inconvenient, since while I can still push it via trmnlp push --id XX, it creates a new recipe every time I do so. Should trmnlp/byos_laravel internally set the ID to whatever was specified as --id when pushing a recipe like this?
• How am I supposed to pull a recipe that was created via the web UI if no trmnlp ID is assigned? For the time being I just used SQLite to update the plugin row and add a random ID myself. Is a more elegant way to do this planned?

[bnussbau]

Hi,

Are these IDs supposed to be universally unique? If I understand correctly, when creating a recipe on usetrmnl.com an ID gets assigned and you can stick with that. However I am not using it and I do not intend to use it, so how should I pick my ID? It would have been nice if UUIDs were used, since by design they are Universally Unique.

Yes, the IDs are intended to be universally unique. If you don't plan to publish the recipe to the official TRMNL catalog, using a UUID is the recommended approach for development with trmnlp.
byos_laravel will do assign an UUID automatically in the future when you clone a recipe via the UI. It makes sense to do this also when you create a new recipe via the web ui.

What should we do with recipes we publish to https://github.com/bnussbau/trmnl-recipe-catalog? For the one I submitted yesterday I simply removed the id from settings.yml. However that's very inconvenient, since while I can still push it via trmnlp push --id XX, it creates a new recipe every time I do so. Should trmnlp/byos_laravel internally set the ID to whatever was specified as --id when pushing a recipe like this?

I would argue that the trmnlp.id in the yaml should be empty when the recipe isn’t published to TRMNL.
I should add a UI control to the recipe detail view that allows managing the trmnlp ID. Will be added in one of the next versions.

In the meantime you can also alternatively use this command to update the field

artisan tinker
# Replace 12 with the recipe id in your url bar
Plugin::find(12)->update(['trmnlp_id'=>'d3898270-c798-455c-9a38-24d4c568a3c4']);
#= true

[depau]

That clears things up a lot, thank you!

@bnussbau
I would argue that the trmnlp.id in the yaml should be empty when the recipe isn’t published to TRMNL.
I should add a UI control to the recipe detail view that allows managing the trmnlp ID. Will be added in one of the next versions.

That makes sense, thanks.

So is it correct to conclude that the following is a bug?

@depau
[...] while I can still push it via trmnlp push --id XX, it creates a new recipe every time I do so. [...]

[bnussbau]

Do I understand this correctly?

• Install the recipe from the catalog (trmnl.id = null)
• Set the trmnlp_id in the database (e.g. a UUID)
• Run trmnlp push --id from the recipe folder (where settings.yml has no id)

This would result in a new recipe being created instead of an existing one being updated .. correct?

If I think it through that may be possible because in the settings.yml the id is null. Would need to verify

[depau]

Actually the state of the DB doesn't really matter.

In the POST plugin_settings/{trmnlp_id}/archive endpoint:

https://github.com/usetrmnl/byos_laravel/blob/94d5fca879b0f7e60b083e067273c821b82b54ad/routes/api.php#L656-L680

the code only validates that the trmnlp_id parameter is not blank, but it never uses it.

In importFromZip():

https://github.com/usetrmnl/byos_laravel/blob/94d5fca879b0f7e60b083e067273c821b82b54ad/app/Services/PluginImportService.php#L118-L141

the code uses $settings['id'] if it is set (this explains the issues with id set to null in settings.yml). Interestingly enough it does generate a UUID if not set.

This might create issues when the plugin is pulled since that would re-set the id field in settings.yml on download.

My opinion is that importFromZip should disregard the id in settings.yml entirely and use the ID provided in the REST endpoint: I think it should be trmnlp's job to parse settings.yml and get the ID from there in case the --id flag isn't specified.

So I suggest adding a trmnlp_id parameter to importFromZip() to forward the ID provided in the REST URL path.

[bnussbau]

0.25.0 adds a UI for trmnlp ID handling in the Recipe Settings dialog via the ⌄ menu. Note that this does not yet change the behaviour if the id in settings.yml is not set.