Plugins clarification badly needed.

Corona Marketplace Corona Community Plugins
#1

Hi,

I am having a hard time getting a handle on the most up to date information on deploying hosted plugins. My users are confused and I am really confused.

I’m looking at this page https://docs.coronalabs.com/native/hostedPlugin.html and am confounded by a number of things.

First, in the Packaging and Hosting section, it says that my .tgz needs to be a flat file (no directories), but pretty much every one of my plugins are built using a directory structure for organization. How exactly am I supposed to handle that without rewriting all references? Why is it different than how it used to work?

Example (S3Lite plugin):

  • s3-lite.lua
  • s3-lite (directory)
    • awsauth.lua
    • awsrequest.lua
    • mimes.lua
      …etc

Secondly, in the Running Plugins in the Simulator section, there only seems to show a path for MacOS based systems. Where do these go for Windows?

Additionally, if my plugins are plain Lua, can I just point to the same url for “iphone” and “android” platforms?

Regarding the “macos” and “win32” being set to false, I have also seen urls there instead (on Scotts plugin metadata entries). How does that aspect work?

And lastly, are downloaded plugins cached? And if so how are they checked for updates? I would prefer not to have a pull every time a build is made.

I’m trying hard to support my plugin users, and I handle the support directly. But I don’t have any good solid information to tell them. Obviously the first issue is that I need to get my plugins hosted, but as I read through the documentation, I’m getting the feeling that I would have to heavily refactor all my plugins, which I have neither the time nor resources for.

Please tell me that this process is simpler than it appears. I want to continue supporting Solar2d, but if I have to rewrite all my plugins, it will be a full stop, and I will have to explain to my users that Solar2d is unable to support my plugins, even though the initial impression was that it would be a very basic transition.

Thanks in advance,
dev

5 Likes
#2

Following - definitely would like to see some clarity here.

1 Like
#3

Yeah definitely need a pair of eyes on the issue. Can’t let the community created plugins start suffering, plus a lot of us love Coronium!!

Help us out!

1 Like
#4

Hi.

A couple weeks ago @vlads posted this on Slack in the #opensource channel:

Hello, folks. I just started a build 3592. It has several improvements, among most important is plugin collector system. There is room for improvements, but I hope this is the final general design.
So, how it works. Any time Solar2D needs a plugin (i.e. it is in build.settings as usual, and required for Simulator or for build), it would ask the system for it. It would query available plugin collectors to get a plugin. There are several built-in collectors.

  • custom URL/self hosted collector
  • local filesystem will return ($HOME or $AppData)/Solar2DPlugins/publisherId/plugin/[build]/[platform]/data.tgz if it exists
  • Free Solar2D directory. This directory contains free plugins. Now it contains all the plugins Corona Labs published. All of them, ready to roll.Also, there is barely tested ability to add custom plugin collectors. This is the place to integrate 3rd party stores. It will try to pick up Solar2DPlugins/Collectors/*.lua files. That files must return function or an object with field collect (and optional fields name and init).
    Collectors have some convenience functions available for them in global namespace. Most notably, fetch and download. Which would make HTTP(S) requests. First will return data as string, second would save it as file.
    Goal of collector is to put data.tgz in destination directory, given description of the plugin.
    I will probably write more detailed documentation, but for now, here is source code. It points to Solar2D free repository collector. It utilizes pretty much all convenience methods described just above it.Any thoughts?

There have been a few builds since then and I’d look at least at 3596.

I think that documentation is slightly off. For one thing, the flat layout doesn’t account for all the Android builds you might do on the native side. Since you have plugins, you must have some of those store-hosted-* directories on hand? I believe the “shape” of layout the collector expects mirrors what you would see there, with the .tgz containing the final contents. With the Solar2DPlugins directory, you could give it a try. :slight_smile: I’ve only lately been trying it with native stuff (both there and via GitHub), so don’t want to claim too much.

There is definitely some caching, though I haven’t delved too deep. Definitely “too much” for development, so myself and a few others have been manually purging from the plugins directory where they end up.

1 Like
#5

Thank you very much for your reply. I truly appreciate it.

I think I am just used to having clean documentation, which Corona has always excelled at. Of course that was a different time, with more resources available. I don’t mind digging around for different pieces of information, but have never been a fan of “read the source code.” And I don’t think that bodes well for new users.

The power of Corona/Solar2d has always been ease of use for those less inclined to get deep in the underlying code. I myself really enjoy documenting, and would be happy to contribute to make the docs more current, but of course I need to know what “current” is.

That wasn’t directed at you by the way. :wink:

Anyway…

So, what I am really interested in is how plain Lua plugins work within this system. Because it seems very different than native plugins. I always have used the plugin build tool to pack the plugins. Yes, I do have “store-hosted-*” directories locally. When updating those, it was a matter of uploading the files in the final plugin folder once the plugin build tool was run.

Is it your impression that I should be able to pack up those files (inside the plugin folder) as a .tgz and get the same result? Any idea on the metadata.json file?

I certainly don’t mind testing this concept, but I just don’t want to start going down dead-end paths if not needed.

Thanks again!

dev

#6

I myself really enjoy documenting

Well, I’m glad somebody does. :sweat_smile:

On that note, I’d be remiss in not mentioning that the docs themselves may now be edited. (If anybody pursues this and needs to actually build the pages, I also have some notes for snags that came with this.)

Barring an authoritative answer, I’d just tar the results of the build tool and start experimenting with the Solar2DPlugins directory, per Vlad’s comments. (Off-hand I expect there are only a few sensible possible arrangements to try.) I don’t think there were any changes “just because”, but rather you’ll now be manually doing what the “builds once an hour” process was doing before.

1 Like
#7

Thanks again. I’ll give it a shot. :+1:

dev

#8

Hi,

So, to document the process, with the hope that someone will see an obvious error in my ways, here is what I have tried so far, with no luck. Again, this is referring to pure Lua plugins built with the plugin build tool.

I packed up my plugin as a .tgz “flat file” which included a directory, and threw in the metadata.json for good measure.

Inside the plugin folder I ran: tar -czvf data.tgz *

I’ve uploaded this to S3 and added the possibly appropriate endpoints:

	plugins =
	{
    ["plugin.s3-lite"] = {
      publisherId = "com.develephant",
      supportedPlatforms = {
        iphone = { url = "https://solar2dplugins.s3.amazonaws.com/s3lite/iphone.tgz" },
        android = { url = "https://solar2dplugins.s3.amazonaws.com/s3lite/android.tgz" },
        macos = false,
        win32 = false
      }
    }
	},

When building for android, the build completes successfully, though no mention of downloading any plugin. But when run on device it fails with “can’t find plugin error, blah, blah.” APK

If I place plugin files directly for the simulator (no .tgz) it seems to work fine. But no love on the build.

I tried to understand the Solar2DPlugins folder thing, but even that was elusive on a fresh Win box with only the latest Solar2d installed.

At this point I just want to know how to add my plugins to the open repository and call it a day, so at least the people using my plugins can continue to do so, at the current versions (I will no longer be updating plugins, except Coronium). Unless I am mistaken, and I probably am, there is no support system for pure Lua plugins.

I’m just really disappointed this wasn’t a bit of a priority. At least in documenting a clear transition path. As much as I love a challenge, due to external factors, I don’t have the time to try and hack this out. How do I post my plugins to the open library?

dev

#9

One thing on the device that seems interesting is that there is a number of (null) placeholders in the alert error, so I am wondering if my packing path is incorrect.

For example:

no file '(null)/plugin/s3-lite.lua'

:man_shrugging:

dev

#10

Hello, I’m a coronium user and I need this to be solved as well since I cannot move to offline builds until this is fixed, cheers

#11

@Develephant let me see if I can help. For my pure lua plugins I first “compile” them. I put them all in a folder and then run this command.

tar -czf gow.lua gowfolder

That is it. But technically if the plugin is just lua your users can download the files and place them in the plugin folder at the root of the project.

I also checked your file. You have tarred the “iphone” folder. You should create the tar inside that folder so that when I un-tar it the iphone folder is not there. It should be just the content of that folder.

2 Likes
#12

I use this app drag folder in and it makes a tgz for you. Best 5$ I have ever spent

1 Like
#13

Thank you. That info is very helpful. I think I was having a hard day, so I’ll try again.

#14

Well I think I found the problem…I’m cursed. :flushed:

I also want to thank everyone who has helped so far. I feel like a complete idiot that I can’t seem to get such a seemingly simple thing to work.

I went for the low hanging fruit, and decided to give the Solar2DPlugins folder a go as opposed to the download option.

So, my directory structure ended up as follows (though I have tried many variations):

/Users/<myusername>/Solar2DPlugins/com.develephant/plugin.s3-lite/android/data.tgz

In addition I have tried:

/Users/<myusername>/Solar2DPlugins/com.develephant/plugin.s3-lite/data.tgz

/Users/<myusername>/Solar2DPlugins/com.develephant/plugin.s3-lite/lua/data.tgz

Now, interestingly enough, if I remove the data.tgz to test compilation, it certainly fails on the build. But, once the file is in place the build completes without error. I load the .apk on my device and I get a runtime error (as in every other configuration I’ve tried). Why?

I’ve now tried this with a single file plugin, and a plugin that contains a directory. The results are always the same error.

In my build settings:

plugins =
{
["plugin.s3-lite"] = {
  publisherId = "com.develephant"
}
},

The build process is obviously seeing something, but there is no output in the console to confirm, just the fact that it doesn’t error on build. Though again, it errors on device.

I still have questions about the need for the metadata.json file, should it be metatdata.lua? Do I even need that anymore?

Would anyone mind sharing with me a packed pure Lua plugin so I can see the content structure?

Testing Files

Want a free S3-Lite plugin? Here is the data.tgz and docs. It’s supposedly placed in the first directory structure above (for MacOS).

The test APK can be downloaded here. You should be able to see the error message when run on device.

Other notes:

Running on MacOS High Sierra
Solar2D build 2020.3597

Off to lay in the grass for awhile…

dev

#15

I have created two projects and repacked your plugin.

The first one, I just placed your plugin in a folder at the root of the project.
The second project, I repacked your plugin to the correct format, placed it on my server.

With both projects and before I removed the keys: printed out the correct name of my bucket in the console. I hope this helps.

s3lite.zip (161.4 KB)

3 Likes
#16

@agramonte

You, my friend, are a God King!

Thank you so much for taking the time to educate me. Apparently I needed it to be explained to me like a five year old. :slightly_smiling_face:

The entire “plugin system” still could use some rounding at the edges, but I am not complaining. Easy to document, just a little extra pain for users.

You don’t know how much stress this has relieved (like many, I am having a rough year). I wish I had something to give you for your help.

Again, I can’t thank you enough, and if there is anything I can ever do for you, please do not hesitate to ask.

dev

#17

@Develephant you are more than welcomed and it was nothing. you do enough for the community.

#18

A New Thread has been setup to bring clarity to the Plugins issue:

#19

Hi,

I just added them to the open directory, problem solved. :slightly_smiling_face:

-dev

1 Like