Code: Select all
local lib = require("libfilename")
assert(lib)
Package and module interdependence best practices
Package and module interdependence best practices
Need some guidance (an example?) of how to handle package/module interdependence. I think typical best practice for Lua alone is to use require(), something along the lines of
I suppose this also works in Mudlet for code components packaged as .lua files, even though there seem to be some complications with paths and such. What about code contained in packages and modules? Is there an example to look at for a user package/module properly handling the code that is provided by another user package/module?
Re: Package and module interdependence best practices
https://github.com/svof/svof/tree/in-client-svof handles inter-module dependencies - can't comment on how, haven't looked into it lately, but a few people on the forums hare are familiar with it.
Re: Package and module interdependence best practices
Thanks @Vadi. This package is sort of a depressing inspiration (inspiration is the sense that it demonstrates how much is possible, depressing because I do not think I will ever be able to put together that many lines of coherent Lua code).
I am not sure it cuts to the core of my question, and that's my fault for not phrasing it clearly. I think looking at this example did help me to understand my question better, and I will try to clarify further:
I want to understand better the concept of managing *reusable* code within Mudlet, on the developer side and the user side. Reusable may mean across different muds or even different profiles within same mud.
Package concept seems clearly non-reusable to me since it requires to have a separate copy for each profile. At the same time I am confused by the fact that the default profile is created with generic_mapper package automatically included (as well as other packages). Automatic inclusion (never mind the use of the word "generic") to me indicates at least partial reusability, but in that case I would expect the code to be split into 2 parts - the reusable portion that I would expect to be abstracted from specific mud details and pretty much stay the same (unless modified by Jor'Mox), and the customizable portion that could vary profile-to-profile. Same with the package called "echo", looks like each profile is given its own copy of this code in its XML profile file.
Module concept seems to be more compatible with reusability with any code changes that are supposed to propagate across all profiles using that module.
What's not clear to me is what's the expected way for people to manage their code when splitting it into reusable and profile-specific portions. Is the user expected to install both the module(s) and the package, or the package installation script should handle the module installation as required? Are there code snippets that demonstrate how it's done?
I am not sure it cuts to the core of my question, and that's my fault for not phrasing it clearly. I think looking at this example did help me to understand my question better, and I will try to clarify further:
I want to understand better the concept of managing *reusable* code within Mudlet, on the developer side and the user side. Reusable may mean across different muds or even different profiles within same mud.
Package concept seems clearly non-reusable to me since it requires to have a separate copy for each profile. At the same time I am confused by the fact that the default profile is created with generic_mapper package automatically included (as well as other packages). Automatic inclusion (never mind the use of the word "generic") to me indicates at least partial reusability, but in that case I would expect the code to be split into 2 parts - the reusable portion that I would expect to be abstracted from specific mud details and pretty much stay the same (unless modified by Jor'Mox), and the customizable portion that could vary profile-to-profile. Same with the package called "echo", looks like each profile is given its own copy of this code in its XML profile file.
Module concept seems to be more compatible with reusability with any code changes that are supposed to propagate across all profiles using that module.
What's not clear to me is what's the expected way for people to manage their code when splitting it into reusable and profile-specific portions. Is the user expected to install both the module(s) and the package, or the package installation script should handle the module installation as required? Are there code snippets that demonstrate how it's done?
Re: Package and module interdependence best practices
Most people include the dependencies inside their package, or include instructions to install the necessary package dependencies. I've been working on a mudlet package repository and install solution that'll do some basic dependency resolution but it's still a little ways off.
Re: Package and module interdependence best practices
Which is to say, package developers are usually working under the assumption you'll install their package per profile. Packages came first, and then modules were sort of bolted on afterward to allow sharing code between profiles. So there's not really a particular 'standard' for this, it's been handled in several ways. Which is part of why I'm trying to come up with some sort of central utility to assist in finding and installing packages and their dependencies.
Re: Package and module interdependence best practices
@demonnic
Yes, something like what you are describing but perhaps not as ambitious. My initial feeling is that the global repository is typically built upon the concept of a shared codebase within the same computer. For example, if my Ubuntu software updates bash shell or the web browser, it will not do so for every user account separately. There is typically a single copy of a shared library, etc. I guess what I am getting at is that I think there needs to be a clear concept for reusable codebase handling within the same Mudlet install to build upon into a global repository. If I understood you correctly that's not yet fully conceptualized.
The starting point I think would be have a single location for the shared codebase, rather than by-profile. For Lua, how hard would it be to add directory to the lua search path a "lua" on the same level as "profiles" directory in the Mudlet folder? At the moment I can add lua shared code to computer-wide lua directories (/usr/local/lib/lua/5.1 and /usr/share/lua/5.1). For Mudlet-specific lua code it seems more appropriate to put it into a subfolder in the mudlet directory. Same would also seem natural for modules ("modules" subfolder?), and, interestingly, there is already a "moduleBackups" subfolder at that level.
Yes, something like what you are describing but perhaps not as ambitious. My initial feeling is that the global repository is typically built upon the concept of a shared codebase within the same computer. For example, if my Ubuntu software updates bash shell or the web browser, it will not do so for every user account separately. There is typically a single copy of a shared library, etc. I guess what I am getting at is that I think there needs to be a clear concept for reusable codebase handling within the same Mudlet install to build upon into a global repository. If I understood you correctly that's not yet fully conceptualized.
The starting point I think would be have a single location for the shared codebase, rather than by-profile. For Lua, how hard would it be to add directory to the lua search path a "lua" on the same level as "profiles" directory in the Mudlet folder? At the moment I can add lua shared code to computer-wide lua directories (/usr/local/lib/lua/5.1 and /usr/share/lua/5.1). For Mudlet-specific lua code it seems more appropriate to put it into a subfolder in the mudlet directory. Same would also seem natural for modules ("modules" subfolder?), and, interestingly, there is already a "moduleBackups" subfolder at that level.
Re: Package and module interdependence best practices
You can add items to the search path for lua's modules (IE using require) pretty easily. it's package.path for .lua files and package.cpath for c extensions.
I don't know that we would be best served by adding another item to keep track of on top of Mudlet modules (global mudlet package installs), mudlet packages (limited to a single profile, but can have additional resource files), and lua modules which don't get used by mudlet scripters very often because there's a lot of interaction with Mudlet which occurs outside of lua. Managing triggers and aliases within lua code alone can quickly become unwieldy and much more difficult than doing it in the GUI.
I don't know that we would be best served by adding another item to keep track of on top of Mudlet modules (global mudlet package installs), mudlet packages (limited to a single profile, but can have additional resource files), and lua modules which don't get used by mudlet scripters very often because there's a lot of interaction with Mudlet which occurs outside of lua. Managing triggers and aliases within lua code alone can quickly become unwieldy and much more difficult than doing it in the GUI.
Re: Package and module interdependence best practices
Also, the concept of managing things in 'user space' (per user, or profile) is not unheard of, and in some cases may be preferable.
Re: Package and module interdependence best practices
Yes, I think I saw the search path modification workaround someplace (I am thinking Vyzor).
I guess I am thinking it through like this. Let's say I want to use EMCO module in my package. Like you said, I can install it anywhere I want and modify package.path in my package, and that will work. Somebody else may want to use EMCO for their package and they will put their own copy of EMCO wherever they want. This is a perfectly fine way to do things, but that's not what I was talking about. If both packages are utilizing the same EMCO library, it makes more sense to me for both packages to just use one copy of that library, not many. But, in that situation, if let's say I want to use EMCO that may have been installed by another package, I do not know where to look for it unless there is a default location where it is supposed to go. And, if there is a default location it makes sense to add it to the lua search path rather than have everyone add the workaround code that adds the same default location to package.path.
I tend to agree about non-Lua things, because other items (triggers/aliases/etc.) tend to be more mud-specific. But there may still be some reason to have a shared copy of some items, like a template for customization? I do not know, haven't thought about this too much. Do not want to exclude the possibility offhand, but it's not really what I am after. Myself, I would be happy if let's say "lua" (or some other name?) in the top level of Mudlet data directory was established as the default location for lua extenstions, and is included in the Lua search path. Would that be difficult to implement?
I guess I am thinking it through like this. Let's say I want to use EMCO module in my package. Like you said, I can install it anywhere I want and modify package.path in my package, and that will work. Somebody else may want to use EMCO for their package and they will put their own copy of EMCO wherever they want. This is a perfectly fine way to do things, but that's not what I was talking about. If both packages are utilizing the same EMCO library, it makes more sense to me for both packages to just use one copy of that library, not many. But, in that situation, if let's say I want to use EMCO that may have been installed by another package, I do not know where to look for it unless there is a default location where it is supposed to go. And, if there is a default location it makes sense to add it to the lua search path rather than have everyone add the workaround code that adds the same default location to package.path.
I tend to agree about non-Lua things, because other items (triggers/aliases/etc.) tend to be more mud-specific. But there may still be some reason to have a shared copy of some items, like a template for customization? I do not know, haven't thought about this too much. Do not want to exclude the possibility offhand, but it's not really what I am after. Myself, I would be happy if let's say "lua" (or some other name?) in the top level of Mudlet data directory was established as the default location for lua extenstions, and is included in the Lua search path. Would that be difficult to implement?
Re: Package and module interdependence best practices
What you're talking about will be solved by the package repository when it's available. I wouldn't worry about solving it on your own, it's a complex task. If you'd like to help we'd love help in https://github.com/keneanung/MudletPackageManager and https://github.com/Mudlet/mudlet-package-repo - that's the future way to go to solve exactly what you're thinking of.
Until then - it's really not an issue if 5kb of code is duplicated in a profile...
Until then - it's really not an issue if 5kb of code is duplicated in a profile...