Nearly out of time! Some final adjustments were made this week, documentation was accordingly updated and preparations are being made to the deliver GSoC's official final submission. Check out the latest changes in this week's blogpost!
Events
Code
1 - prosodyctl: fixed a typo2 - util.startup: changed the way util.paths.complement_lua_path was being accessed
3 - util.paths: fixed another typo
4 - util.pluginloader: Added a new path to the variable local_names
5 - core.configmanager: Removed code related to complement_lua_path
6 - prosodyctl: install, remove and list commands now use the call_luarocks function
7 - util.prosodyctl: Removed the check_flags and execute_command functions
8 - util.prosodyctl: call_luarocks function now sets the directory variable itself
Documentation
These are planned changes to the already existing documentation that you can access at prosody's website. For example, you can check prosodyctl's page through the link: https://prosody.im/doc/prosodyctlChanges:
doc.prosodyctl: Got rid of the text related to the --tree flag, which has been removed
doc.depends: Added Luarocks as a dependency, and related info
doc.plugins_directory: Added info related to the plugin installer's directory configuration
doc.plugin_installer: Gave the .md extension and rewrote this file
doc.installing_modules: Added info about the plugin installer's directory and which paths it checks
Difficulties/Considerations
After talking with my mentor, we ended up removing the --tree flag from the installer, for now, as it was not clear how useful it would be.
Initially we though it would be nice to also give the user the possibility of specifying the working directory from the command line. Why would him want to have new plugins at different directories for the same prosody server though, since he can use the installer now to easily list and install/remove them, while have everything organized at a single directory?
Behind the scenes, it would also require more work than what I had done. When started, the prosody server goes through a startup process. Some of the things it does are:
- complement lua's package.path and package.cpath
- check for plugins in a number of directories, that are part of the default/configured plugin paths
When using commands with the --tree flag, prosody would have to go through these startup tasks again, so that these new paths are taken into consideration, in future operations. We would need to, in a way, reload prosody each time one of these commands were run, so that all the paths could be updated.
At the end of the day, it seems to be too much hassle for a seemingly redundant feature in project that is meant to be lightweight and simple.
This might be a thing to reconsider in the future, but, for now, the user can use the default path for community modules or set a new one at the configuration file, similar to what we already do for the core plugin directories.
This might be a thing to reconsider in the future, but, for now, the user can use the default path for community modules or set a new one at the configuration file, similar to what we already do for the core plugin directories.
See it in action!
You can check this video out, were I install mod_message_logging. I'm using this one here, because it is simple to demonstrate that the plugin is really installed and being used by the software.
Future goals
GSoC's final submission is in demand, so this week we are tackling that, so that everything is nicely presented at the end. See you soon!
Comments
Post a Comment