How can we encourage developers to build plugins based on other plugins?

1. I think it's mainly because no-one knows that other plugins have an API that can do that. Also contributing is, that we don't have a place where all plugins are listed, so plugins get created without knowing there is exactly that plugin already existent. And writing, designing and documenting an API is hard, and most devs don't see the use of doing so, so they won't do it. As a result, most devs don't even expect that particular plugin to actually have an API, due to only very high quality plugins do have an API. Also most APIs are only some get() function that don't do much.

2. We need an unique plugin list, where most plugins should be listed. But that won't really help.

hz8/ <-[EDIT] WTF how did that get there?

 

As I develop plugins too, I have this reason for it; In my eyes it's somehow more fun to code a new plugin, rather than using a plugin and building upon it. It just feels like you've done more to make the plugin.
The second reason for me is because I don't personally like my plugins to depend on other plugins, because users must download an other plugin to use yours, while maybe not even liking it. It just feels like it's more convenient to make own API methods for easier use of the plugin.
I do however agree it shouldn't really be like this. For example: Purechat is an awesome plugin, which extends PurePerms in a very good way. Simpleauth + SimpleAuthHelper is another one of these examples. (even though the 2 are both kind of outdated)
I think those two example plugins are pretty well-known and used a lot.

 

Whilst extending other plugins is a something every developer here should know how to do (if you can extend pocketmine itself enough to make a plugin you should find it pretty easy to extend other plugins' functionality if they have working API's) but people don't seem to do it that often. The main reason for this, in my opinion, would be the lack of people knowing that it is possible to do so (or people are just too lazy to find an existing plugin to extend).

The other main cause of this may be the fact people dislike or despise dependencies (most of us developers here will more than likely somewhat agree with this). Dependencies are a pain in the neck for multiple reasons:
1.) Dependencies often have other dependencies — This makes it a pain for the people using the plugins, having to download and configure multiple plugins just to get one plugin to work is no fun and nine times out of ten people complain about plugins being broken because they don't understand why it won't just work by itself. I am also completely aware you could use soft dependencies that rely on configs but you'll always end up with someone not knowing what any of your comments mean.
2.) We're making plugins for anyone, not just developers — We all need to remember that we're not just writing plugins for ourselves or other developers; we're making plugins for anybody, with most of anybody (in this case at least) being kids or young adults. Your average pocketmine user will most likely not understand what a dependency is so they'll be sitting there scratching their head wondering why someone would be stupid enough to make a plugin that doesn't work or if they have a rough idea of what a dependency is they'd be wondering why someone would be stupid enough to make a plugin that relies solely on another plugin.
3.) Dependencies lead to more dependencies — If it started becoming the norm to build plugins around other plugins' API methods the chances are someone else will make a plugin that will use your plugins API methods then someone else will make a plugin using that plugins API methods and this can continue on for an infinite amount of times. This is perhaps the most annoying issue when using dependencies in things like plugins, people don't want to install five parent plugins just to get one plugin working.

Overall there is a lack of plugins making use of other plugins' API methods and it would be good to see some plugins do so as writing good API methods takes time and a lot of thought, but there is a point at which it needs to be limited or we could end up with a plugin repository full off dependency upon dependency.

This is just my two cents on this thought, so feel free to critique or question anything I've said

 

Also some people are really awful at maintaining projects. So even if they are updated, you don't have a guarantee that the API is safe. So depending on them isn't safe. I always consider my external API when I build a plugin. And I don't change it. EVER!

Just to pull an example (not pointing blame at all), I added support for EssentialsPE in SimpleWarp by soft depending it. This was because EssentialsPE started using the same commands as SimpleWarp and this annoyed a lot of users. With my solution, If a user tried to go to an EssentialsPE warp, I would call the relevant method in EssentialsPE. I added this support after I became the official maintainer of EssentialsPE (which lasted a couple weeks), because I thought I would be able to control both projects and force them to support one another.

@iksaku took EssentialsPE back, and now @SanderTv has it. Both of them pushed the plugin forward and tried to fix API issues that had been present in earlier versions. However, in doing so, they broke the API. They changed method names and failed to make it backwards compatible.

This puts me in an awful situation. if I want to continue supporting EssentialsPE, I need to check which version is running and call the right method name. That is too much work to maintain. And people are creating issues on my repo, when it's hardly my fault.

As far as solutions go, if you want your plugin to have an API, you need to make it a priority. You need to make sure it doesn't change and if it does, you provide notice and guides on updating. And if you are willing to do all of this, advertise your API in your README and plugin description. That way other developers can figure out the difference between an API that is intended to be public and one that wasn't built for reuse.

As a suggestion for Poggit, maybe have a flag like "public-api", which would keep track of plugins that exposed good APIs with some documentation. They could undergo an additional review process.

 

I have in fact not changed the API a lot yet, mostly fixed some bugs and added to the update iksaku was planning. Feel free to tell me if you want something different or if I can help you, I'll happily revert any API breaking commit that makes (for example) SimpleWarp not work.

 

Thanks

I misrepresented that a bit. See https://github.com/Falkirks/SimpleWarp/commit/508e8f06e1f1e8910b06e7973ca20c3a916d4a1e. That is something which didn't need to happen. I have handled it and it's in the past. But at the time there would have been better ways for the change to be made

That change and the response I had to take, made me lose confidence in the public API. That could have been avoided by adding some backwards compatibility methods or by making a note in the repo about upgrading.

Again, It doesn't matter much to me at this point. I just want to provide this as an example to other developers of how simple changes to public APIs can mess up things for other developers. And how we can handle that better in future.

 

In fact adding an api to a plugin is my favorite thing to do while creating a plugin. I tried implementing an API to my HungerGames plugin where it can easily be extended, and I just called them "scripts". Do you think the plugin has a good enough API to keep maintaining it?https://github.com/InfinityGamers/HungerGames-UPDATED

 

Oh oh oh. I wanted to post this somewhere, but couldn't decided where. This thread got me thinking about how I could make my SimpleWarp API more fun to use. And what parts are tricky to understand. I also thought about making a plugin that can be extended and not just used. I decided to make two rather large changes (which broke my internal API a bit).

1. Save data automagically.
   If another developer sets the destination of a warp, it should be saved just as if a user set it. Previously you would need another line of code to trigger an update, now warps trigger their own updates. Plugin developers shouldn't have to navigate silly internal APIs, if they want to set a warp to public it should be as simple as $api->getWarp("name")->setPublic(). There shouldn't be any need to navigate a data storage system of other internal constructs, let that be invisible. The trade-off for this is that warps have a reference to their manager class, but that isn't too bad in the long run.
2. Let users attach arbitrary data.
   In order to make sure the SimpleWarp API was usable, I wrote a couple full plugins using it. In both those projects, the part which took the most time was setting up the config. The config was basically mapping some data to a specific warp name. Like maybe a user who owns the warp or a portal trigger coordinate for that warp. So the obvious way to make this easier was moving this data into SimpleWarp. I added metadata to warps, so other plugins can set fields and get them later. This means they can leverage my storage and indexing system. And it makes it easier on the server owner, having all the information about a warp in one config file. See https://github.com/Falkirks/SimpleWarp/wiki/Metadata.

 

I'm one to prefer immutable objects with clearly-defined behavior. But that's just me.

 

Fair enough. There are trade-offs for each course of action. But having a setter method implies that it will be "set" properly and in my plugin that means propagating it to a config. The immutability is something else. My objects were never immutable. I have always had setter methods in them, they just didn't modify the underlying data file. So it was kinda halfway between immutable and mutable, and my point is that picking one is important.

 

Yes, I agree! But I do think there is a difference between internal and external APIs. A good plugin will have a lot of overlap between the two though. There are some functions that change often or are central to the plugin, which are internal API. And sometimes, we create API elements that are only external, like firing events inside a plugin.

We just share repos on there. Most repos have one of two maintainers, those people decide what is going on with the project. EssentialsPE was always developed by @iksaku (and now @Blabla), it was just hosted with LegendsOfMCPE.

 

I'm currently in the progress of making an extension. The best part is: I can use the DB from the main plugin, by using its API. That is saving me so much time, and others should be aware of such things. I'm also developing a plugin where i try to design an API, i'll see if i can make an API-how to create one? Guide.

 

will do that

 

I would implement some APIs into my plugin, but there's no tutorial. D: