Well, this feels interesting. For me, having a single copy of shared code is sort of part of basic coding hygiene, a never questioned paradigm. So, I feel like as if someone said to me - "no we do not have functions, but you can easily cut and paste your code if you need to repeat it. You can have functions when we have online function repository going". I find myself wholly unprepared for that kind of conversation, but I always appreciate it when my world is shaken to the core and have to be rebuilt up from the ashes.
Kidding aside, it's not the end of the world. There are workarounds, and I am not averse to cut and paste code when I need to.
Package and module interdependence best practices
Re: Package and module interdependence best practices
I think we're talking about different things - there is no need to duplicate code. Dependency management is not the same as deduplication, not exactly. It's perfectly possible to have a function in another module and call it as needed...
Re: Package and module interdependence best practices
@Vadi
I think dependencies become an essential part of code deduplication effort as soon as you move the scope of discussion to something more than a single monolithic package, but that's a far more abstract discussion than I intend to have here.
I was just looking for examples of how to do this - split off your own reusable code (into a module?) that can be used by somebody else's package, and use somebody else's shared code (module?) from within your own package. Seems to me that the current practice at the moment is to just copy a chunk of somebody else's code into your own package. So, I think it would not be unfair to say that the current practice of reusing the code is code duplication. At least that's the impression that I am getting so far. I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile. The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage, or I am lacking the understanding of how to do it properly. Which brings me back full circle to examples of such usage.
I think dependencies become an essential part of code deduplication effort as soon as you move the scope of discussion to something more than a single monolithic package, but that's a far more abstract discussion than I intend to have here.
I was just looking for examples of how to do this - split off your own reusable code (into a module?) that can be used by somebody else's package, and use somebody else's shared code (module?) from within your own package. Seems to me that the current practice at the moment is to just copy a chunk of somebody else's code into your own package. So, I think it would not be unfair to say that the current practice of reusing the code is code duplication. At least that's the impression that I am getting so far. I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile. The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage, or I am lacking the understanding of how to do it properly. Which brings me back full circle to examples of such usage.
Re: Package and module interdependence best practices
> Seems to me that the current practice at the moment is to just copy a chunk of somebody else's code into your own package.
Where do you get this idea from?
> I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile
Yes - so people can tweak and customise it as necessary.
> The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage
They're not limited, and the module's goals fulfil what it's supposed to help with: removing code duplication from profiles. Many people have more than one profile, and so of course they don't want to duplicate code across them - that's what modules solve.
Can I ask what your programming background is? It's difficult to have this discussion not knowing what you're capable of, and I've failed to zero in on what it is (since the svof example was too much).
Where do you get this idea from?
> I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile
Yes - so people can tweak and customise it as necessary.
> The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage
They're not limited, and the module's goals fulfil what it's supposed to help with: removing code duplication from profiles. Many people have more than one profile, and so of course they don't want to duplicate code across them - that's what modules solve.
Can I ask what your programming background is? It's difficult to have this discussion not knowing what you're capable of, and I've failed to zero in on what it is (since the svof example was too much).
Re: Package and module interdependence best practices
>> Seems to me that the current practice at the moment is to just copy a chunk of somebody else's code into your own package.
>Where do you get this idea from?
Our discussion so far. Since the context is code duplication, I do not see a fundamental difference between pasting the code in as a separate module/package, or appending it to a 100k line file. One way or the other the code is duplicated.
>> I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile
>Yes - so people can tweak and customise it as necessary.
For sure. Still, for something "generic" I would expect to be able to separate the core logic, truly common, generic parts that do not require customization from the customizable bits. If every bit requires customization, I can't see how it can be considered generic. At any rate, simpler examples are always better, so how about 'echo, or deleteOldProfiles. Those parts are also copied over, no?
>> The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage
>They're not limited, and the module's goals fulfil what it's supposed to help with: removing code duplication from profiles. Many people have more than one profile, and so of course they don't want to duplicate code across them - that's what modules solve.
I can see how a module can be used to avoid code duplication in specific case of single mud and multiple characters on that mud. More generally, it allows for more convenient and manageable code structure and de-duplication within a single project, so I should not have denied that it's meaningful usage. I apologize, bad communication on my part. I do think it is limited, as it doesn't extend to the area that I tried to address in my original question - code sharing between different teams/projects. I gave an example of EMCO earlier, asking what would be the proper way to incorporate it into my module/package. Since this type of code is not in any way mud specific, I expect that it should be possible to share that code across multiple mud packages/modules. The only option at the moment I can see for myself is to copy the code into my module/package.
>Can I ask what your programming background is? It's difficult to have this discussion not knowing what you're capable of, and I've failed to zero in on what it is (since the svof example was too much).
My background is in C++/C, learning Lua now because of Mudlet. Frankly I do not think the issue is what I am capable of or what you are capable of, but understanding each other. I am sure you are way more experienced than I am, but the question I am asking I feel is very, very basic even for me
. Hopfully my additional explanations above help us get on the same page here. Let's just focus on EMCO - what is the way for multiple people to use this code for their mud packages/modules?
>Where do you get this idea from?
Our discussion so far. Since the context is code duplication, I do not see a fundamental difference between pasting the code in as a separate module/package, or appending it to a 100k line file. One way or the other the code is duplicated.
>> I mean, even the generic_mapper code that is meant to be so reusable that it's added to every profile, is simply duplicated in every profile
>Yes - so people can tweak and customise it as necessary.
For sure. Still, for something "generic" I would expect to be able to separate the core logic, truly common, generic parts that do not require customization from the customizable bits. If every bit requires customization, I can't see how it can be considered generic. At any rate, simpler examples are always better, so how about 'echo, or deleteOldProfiles. Those parts are also copied over, no?
>> The concept of module is supposed to address this somehow, but it's hard for me to tell if its abilities are quite limited at the moment for meaningful usage
>They're not limited, and the module's goals fulfil what it's supposed to help with: removing code duplication from profiles. Many people have more than one profile, and so of course they don't want to duplicate code across them - that's what modules solve.
I can see how a module can be used to avoid code duplication in specific case of single mud and multiple characters on that mud. More generally, it allows for more convenient and manageable code structure and de-duplication within a single project, so I should not have denied that it's meaningful usage. I apologize, bad communication on my part. I do think it is limited, as it doesn't extend to the area that I tried to address in my original question - code sharing between different teams/projects. I gave an example of EMCO earlier, asking what would be the proper way to incorporate it into my module/package. Since this type of code is not in any way mud specific, I expect that it should be possible to share that code across multiple mud packages/modules. The only option at the moment I can see for myself is to copy the code into my module/package.
>Can I ask what your programming background is? It's difficult to have this discussion not knowing what you're capable of, and I've failed to zero in on what it is (since the svof example was too much).
My background is in C++/C, learning Lua now because of Mudlet. Frankly I do not think the issue is what I am capable of or what you are capable of, but understanding each other. I am sure you are way more experienced than I am, but the question I am asking I feel is very, very basic even for me
. Hopfully my additional explanations above help us get on the same page here. Let's just focus on EMCO - what is the way for multiple people to use this code for their mud packages/modules?Re: Package and module interdependence best practices
I thought some more about this, and I am somewhat amused that I realize this quite late into this discussion, that the things that make me unsure about using Mudlet module feature and Lua require feature are pretty much the same. It's the lack of convention on the location for these common library components. I would not know where to look for already installed libraries and conversely would not know where to put my own libraries for others to easily find.
Re: Package and module interdependence best practices
Already installed libraries are typically available in the global namespace. If you'd really like to use require(), you can, see https://wiki.mudlet.org/w/Mudlet_Packag ... .lua_files.
Re: Package and module interdependence best practices
For sure, one can use require(). Just the other day I have installed a shared Lua library using luarocks, and there was zero problem using that library from within Mudlet using require(). That wasn't Mudlet specific code, just a general use library from luarocks. However, it doesn't seem like the best way to treat Mudlet specific code, since it doesn't have global usability scope so to speak, it is only useable within Mudlet. Otherwise we could have been piggybacking off luarocks repository to distribute Mudlet shared code.
The second option I see is including all of the .lua files I need into the profile directory. I think this is the way presently recommended in the wiki link in your post. I think this is basically code duplication, because that's the way for every profile to potentially having a copy of the code if it does have that level of popularity.
Yet the third way that's already in place would be to pick some place(s) within Mudlet directory to place the .lua library file(s). I could then use the available workaround of modifying packages.path so that Lua can find that file where I put it. The flaw of this last approach is that without convention everyone will have their own idea of what's the best place to put the shared code, so that's a recipe for a mess keeping track of all locations to add to package.path. It just makes code sharing less smooth.
Instead of these 3 less than perfect (at least in my opinion) approaches, I think it would be an improvement for Mudlet development team to "standardize" the shared code location. For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
I have described the way I see things for .lua file and require(), but the same applies to modules. I have preference towards require() for code sharing, but this post is long as is. I will leave my reasoning on that for another day.
The second option I see is including all of the .lua files I need into the profile directory. I think this is the way presently recommended in the wiki link in your post. I think this is basically code duplication, because that's the way for every profile to potentially having a copy of the code if it does have that level of popularity.
Yet the third way that's already in place would be to pick some place(s) within Mudlet directory to place the .lua library file(s). I could then use the available workaround of modifying packages.path so that Lua can find that file where I put it. The flaw of this last approach is that without convention everyone will have their own idea of what's the best place to put the shared code, so that's a recipe for a mess keeping track of all locations to add to package.path. It just makes code sharing less smooth.
Instead of these 3 less than perfect (at least in my opinion) approaches, I think it would be an improvement for Mudlet development team to "standardize" the shared code location. For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
I have described the way I see things for .lua file and require(), but the same applies to modules. I have preference towards require() for code sharing, but this post is long as is. I will leave my reasoning on that for another day.
Re: Package and module interdependence best practices
> Otherwise we could have been piggybacking off luarocks repository to distribute Mudlet shared code.
I don't think so - have you tried to install LuaRocks on Windows?
> For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
And how should things work if files there need to be updated, or better yet, deleted? Let's flesh out this idea further.
I don't think so - have you tried to install LuaRocks on Windows?
> For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
And how should things work if files there need to be updated, or better yet, deleted? Let's flesh out this idea further.
Re: Package and module interdependence best practices
>> Otherwise we could have been piggybacking off luarocks repository to distribute Mudlet shared code.
>I don't think so - have you tried to install LuaRocks on Windows?
You got me, I have no idea how easy/hard it is to use luarocks under Windows. Sounds like it's a pain.
>> For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
>And how should things work if files there need to be updated, or better yet, deleted? Let's flesh out this idea further.
I am not sure deletion is necessary. If the library is not require()-d (or, in module's case, the module is not installed in the profile), having it available is not a detriment.
Updating is a more complex issue in my opinion. As described, the suggested change doesn't call for any extra update functionality to be implemented in addition to what's there. I would assume the file(s) would have to be copied over when a library needs to be updated, same way it's done now I believe. The only difference would be the common location for the library files, in contrast to the present situation where the options are 1) system-wide (not cross-platform compatible) 2) per profile (duplication) 3) arbitrary (complexity/duplication). It seems to me it's a step forward, even if it's not the final step. In the future versioning and update functionality can be added for sure. The only potential problem I see is if this approach is not compatible with long-term vision for Mudlet shared libraries, but I do not see how since this vision I do not think is described anywhere. Also, I would be concerned with any foreseen solution that doesn't involve single copy of shared code.
>I don't think so - have you tried to install LuaRocks on Windows?
You got me, I have no idea how easy/hard it is to use luarocks under Windows. Sounds like it's a pain.
>> For Lua files it would mean hard coding that location into Mudlet so that one doesn't have to set packages.path manually, making sure that the directory is created at the install time, and add recommendation to use that location to the wiki.
>And how should things work if files there need to be updated, or better yet, deleted? Let's flesh out this idea further.
I am not sure deletion is necessary. If the library is not require()-d (or, in module's case, the module is not installed in the profile), having it available is not a detriment.
Updating is a more complex issue in my opinion. As described, the suggested change doesn't call for any extra update functionality to be implemented in addition to what's there. I would assume the file(s) would have to be copied over when a library needs to be updated, same way it's done now I believe. The only difference would be the common location for the library files, in contrast to the present situation where the options are 1) system-wide (not cross-platform compatible) 2) per profile (duplication) 3) arbitrary (complexity/duplication). It seems to me it's a step forward, even if it's not the final step. In the future versioning and update functionality can be added for sure. The only potential problem I see is if this approach is not compatible with long-term vision for Mudlet shared libraries, but I do not see how since this vision I do not think is described anywhere. Also, I would be concerned with any foreseen solution that doesn't involve single copy of shared code.