Open dktapps opened 1 year ago
I would like to see those changes Poggit could start to only offer .zip plugins from now on and when pm7 releases phar plugin support can be removed completely The change should be forced slowly or just add support for both types Then everyone would be happy I guess
yeah pls
Which types of zip archival would be supported and what features within the spec would be supported?
I'd be interested to see pocketmine allow for password protected zip archives to be loaded with the password specified somewhere.
I haven't actually thought about the password protecting stuff.
I think encrypting stuff in that manner is probably better left to plugins.
.phar .zip why not folder? :(
I'm currently leaning towards a custom file extension like .pmplugin
in a similar manner to .mcpack
and friends.
One downside that just occurred to me is that developing a plugin that depends on another plugin might get a bit more inconvenient if zip
becomes the standard, as PhpStorm won't automatically index code found in zip files.
Another downside to zip is that some linux systems don't have zip utilities installed by default since zip is rare in the linux ecosystem. The tar format is mostly used instead along with the tar
utility.
I'm currently leaning towards a custom file extension like
.pmplugin
in a similar manner to.mcpack
and friends.
According to the php documentation, PHAR files may be of zip or tar format instead of the custom phar format, using this would keep the same extension / usage while being easier to unarchive.
So the format would be a tar/zip archive with .phar extension and the stub located in .phar/stub.php
.
Plugins don't need stubs. We don't need to bring phar or ext-phar into the picture at all.
One downside that just occurred to me is that developing a plugin that depends on another plugin might get a bit more inconvenient if
zip
becomes the standard, as PhpStorm won't automatically index code found in zip files.
Many plugins already have a composer.json, which is more friendly for static analysis. Those who care about importing paths might as well just use composer.
Many plugins already have a composer.json
Many more don't. The ones using composer are far from being the majority.
For posterity: When_ used by a file included from a zip (e.g. zip://plugins/MyPlugin.zip/src/Main.php
), __FILE__
and __DIR__
don't include the zip://
URI prefix, meaning that attempting to access files relative to __FILE__
and __DIR__
won't work correctly automatically. This is probably a bug in ext-zip
. We can solve this by using phar://
(which does support zip natively, funnily enough).
THIS IS A PROPOSAL
Before getting mad in the comments, please note that this is a change proposal. It doesn't mean this will definitely be implemented.
Description
.phar
has been the standard for public plugins for many years. However, it's inconvenient and esoteric.The only reason to use Phar in the general PHP world is because
.phar
files can be run like.php
files using thephp
executable. However, no one runs plugin.phar
files directly anyway, so this is a moot point.Justification
Zip plugins would have the following advantages:
unphar
websites needed to view contents (they probably make almost all of their business from PM plugin devs).mcworld
,.mcaddon
and.mcpack
which are all dressed-up zipsHowever, the following downsides:
/extractplugin
in DevTools.Past precedent
This was implemented by a plugin in the past by @alejandroliu as seen here: https://github.com/Muirfield/pocketmine-plugins/tree/ZipPluginLoader-1.2.0/ZipPluginLoader
However, a modern implementation of this would be drastically simpler.
Alternative methods