ModMan
Monkey Forums/Monkey Programming/ModMan
| ||
| I've just had a quick look at the module manager and while I'm glad to see something happening in that area I've got a bit of a concern about the way it functions. Currently it just pulls the latest changes from a repo. This gives the module admin no way of controlling public releases except by working in a dev branch. It currently offers no method of displaying release information before updates and if it did would presumably also require some specific mechanism in the repository commit notes or similar. More significantly there's no way to flag dependencies. I appreciate that there's a certain convenience to just wrapping repository functions but the above are all reasons why most package managers work via other mechanisms. It's also notable that the convenience of using the repo functions doesn't transmit to the newbie user who may well not have hg or git installed. |
| ||
| Some thoughts about modman. Updating and uninstalling? I would like to see a list of modules I have installed. I can see my version number and I can see the latest release version. I select the module from the list and see what the update entails and if I want I can click "upgrade". 1 min later I have the new updated version and can go back to coding. How to find new mods? I assume a list of mods, it will probably be quite long 100+, maybe have tags that can filter the list? Should still be scrollable or can even be on this website with a unique install via client link. Each mod has a name & when selected one can see the mods description text. Each mod has a version log, one entry for each monkey version so one can check what is new. It also has a verified with <monkey version nr>. It is up to the module authors & admins to verify a framework works each monkey release and "update" the version number if they so desire. The idea is not to ensure every mod is always updated, but so that users can make wiser selections if modules go out-of-date because of monkey api updates. How to add/update mods? I guess the best would be to use the website's account system for this. Allow mod-authors to add mods + all fields & description and upload a zip. I'm seeing a basic yet practical implementation. |
| ||
| for something like this, i feel BRL should hire another person for a nominal fee. |
| ||
| That might be a good idea, probably better for this to be a separate App that can be linked from any IDE for example. Maybe something that can be done in wxMonkey easily? |
| ||
| app soup in the developer toolchain is one of the main reasons people spring for an IDE like Jungle in the first place -- to reduce the amount of switching people have to do to get something done. It's right there in the name -- Integrated Development Environment -- Just a nugget of food for thought ! Edit: aaaand, I just realized that OP is not ziggy, and that this is a completely different module managing system being talked about on this thread. Welp. |
| ||
| @Noboyuki: This will be integrated into Jungle Ide. |
| ||
| Modman is really just meant to be a simple, convenient way for users to install/update the various existing git/hg repos' out there. I don't have the time/skill to build an entire update system 'from scratch' so this is kind of a compromise. Yes, it means you need to have git/hg installed, but that's not difficult and perhaps these could even eventually be packaged with the Monkey release if this gets to be useful enough. The upside of this approach is that most Monkey modules are already on git/hg somewhere, so it's kind of zero effort for module developers to deal with. The only real issue is that some repos' (eg: diddy) don't have the module in the 'root' of the repos which modman can't yet deal with, but should. The list of modules is currently hardcoded in, but this will eventually be pulled from monkeycoder.co.nz or something. This list will be maintained and updated by BRL (so there's at least a minimal guarantee that modules 'work'), although it should also be possible to pull modules lists from elsewhere. |
| ||
| But it's not zero effort for module admins, that's pretty much what my first post is all about. It demands specific repository usage and will always do so. A "from scratch" update system that doesn't use source repository functions is as simple as just defining a package format and code required to download and decompress a zip file. I don't see how the repository bit is saving much effort in creating the manager or in administering a module. |
| ||
| > But it's not zero effort for module admins, Any system will require some effort if modules require master/develop branches - whether it's 'merge with master' or 'edit info file, zip and send to mark'. But many don't - probably currently most - and they will 'just work' as is. All the modules currently in modman (except diddy) are IMO perfectly usable and the authors (or me) didn't have to do a thing. > A "from scratch" update system that doesn't use source repository functions is as simple as just defining a package format and code required to download and decompress a zip file. ...and serving those zips from somewhere, and making sure authors keep them up to date (or am I supposed to?) , and dealing with versioning issues and potentially reverting bad updates etc - a bunch of stuff we get for free using existing repos'. Dunno, just struck me as a low overhead way of tracking all the Monkey module developments going on out there - what's the general opinion, good idea or not? |
| ||
| ...and another thought, if modules are just zips, why not just add them to releases - ie: each weekly-ish monkey update could contain the latest versions of a bunch of modules in modules_ext? This is probably easiest of all! |
| ||
| ..why not just add them to releases.. works for me! |
| ||
| You're not addressing any of the issues I raised to do with version definition or controlling releases. The fact that anyone using modman just ends up with whatever random last commit I make to box2d isn't a workable situation. The repository is where I work and I don't expect an update system to put requirements on me to work in specific ways. Yes zip and definition files would have to be hosted. You could host them or you could require external hosting (mostly these things end up mirrored fairly rapidly). Server capacity for the size of files we're talking about to be distributed to a few hundred or thousand users isn't exactly a scarce resource these days. Who should make sure they're up to date? How would that be the responsibility of anyone other than the module admin who wants to do a release? I don't understand where your concern lies. |
| ||
| >You're not addressing any of the issues I raised to do with version definition or controlling > releases. The fact that anyone using modman just ends up with whatever random last commit I > make to box2d isn't a workable situation. If box2d only has a volatile develop branch - and you're unwilling to add a stable master/release branch - then yes, you're hosed. > The repository is where I work and I don't expect an update system to put requirements on me to work in specific ways. If you are working on a module without git or hg, or your repos does not have a stable branch, then you'd have to create a separate 'modman' repos and push stable releases to it. |
| ||
| Yes, I'm aware of the consequences of your implementation choice. I pointed them out in the first post. They're why it's a bad concept. I'm not hosed, by the way. The users of modman will be. |
| ||
| A "from scratch" update system that doesn't use source repository functions is as simple as just defining a package format and code required to download and decompress a zip file. I don't see how this is any easier for module devs than just having the stipulation that to be listed in modman, one must have a stable branch or 'modman repo.' Both are format stipulations for modman inclusion and neither are untenable for mod devs. The current modman solution is fairly easy and straightforward. Anything much more might require a separate maintainer... |
| ||
| > Yes, I'm aware of the consequences of your implementation choice. I pointed them out in the first post. They're why it's a bad concept. And what about the consequences of your implementation choice? * Having to write/maintain the thing. * Having to secure the upload system (or manually upload myself). * Having get people to 'opt-in' in the first place. * Having to rely on people to provide timely updates. At least, I think that's what you implying - you haven't really described what you're after beyond 'describe a package format and download a zip'. Like I said, it's a compromise. The goal is to make as many modules available as easily as possible, and IMO this is a good way to achieve that without having to write a full blown module manager - something you seem to think is trivial but I have serious concerns about. I would still also like to hear what other people think of the modman approach too - if no one likes it, I'll probably drop it. I'm warming to the 'just dump a bunch of modules in modules_ext' idea too... > I'm not hosed, by the way. The users of modman will be. Sorry if you took 'hosed' the wrong way...was trying really hard not to be snarky. |
| ||
| You think using zip files for distribution is as much of an ask as insisting that everyone creates repositories specifically for modman? Ubiquitous, everyone uses them, standard zips versus a repository requirement that doesn't match how many people work even if they use git/hg in the first place. You're aware that nearly all the modules out there already provide zip file releases to avoid users having to install hg/git to get the module? As for "anything much more might require a separate maintainer", care to elaborate? As I pointed out, the actual "get the latest module" bit of the module manager is hardly easier to implement via hg/git than it is via zip files. What's the trade-off here? What benefit is going to come from insisting on using direct repository access that will make up for the issues I've raised? |
| ||
| * Having to write/maintain the thing. I still don't see what you think zip downloads add to this problem. * Having to secure the upload system (or manually upload myself). If you have an upload system. There's no reason why you can't just pull the files automatically from the "trusted" module source in the same way you trust the repository. * Having get people to 'opt-in' in the first place. A valid problem with any system but this is primarily a community issue. I'm not sure your choice of simply grabbing stuff that's public to avoid interaction with module admins is a great response but using the repositories isn't a technological requirement to do that anyway. You could just as easily be pulling the publicly available zip downloads. * Having to rely on people to provide timely updates. I don't understand what this means. The modules are released when they're released. Any update is defined by that release. When it's done is as timely as you can get. Are the Monkey zip releases somehow not timely because the repository sees changes first? Edit: By the way, I'm willing to put some effort into creating an alternative solution. My only concern would be that such effort would be wasted if you've set your mind on this direction. |
| ||
| Ok, I *think* I see where you're coming from (I hope). I have no real issue with modman grabbing zips alongside the ability to 'git update' etc. Ditto, I have no theoretical problem with modules being 'tags' or 'submodules' or whatever. I'm basically OK with kludging modman to pick up modules from a variety of sources - whatever makes it easier for users to publish their modules. What I don't want to get into is BRL hosting modules, or being some kind of 'module server' or authority or whatever (beyond maintaining a module list), which is what I thought you were implying. |
| ||
| No, I've got no position on whether BRL actually hosts the modules and wouldn't really want to be uploading files to BRL or emailing you about updates. I can imagine some people might like it if BRL offered module hosting via the user account but I think most of the current module authors don't really need it as they already have file hosts. The most I'd expect is an email or some sort of form to input the details of new modules or changes to the source location. Updates would probably be better off dealt with by retrieving version xml/json/whatever files from the module source in most cases. |
| ||
| I would be OK with including them all in a release. Or a repository named modman that you push the release you feel is most stable for general consumption. |
| ||
| Mark mind if I ask why you want to avoid hosting the modules ?, you seem fairly set against the idea. To be honest the way I thought this was going to end up was that BRL would host an official list of modules and their files, these would be major versions, meanwhile the module developers would self host on git or what ever and ONLY push major updates to the Official BRL system. Pulling direct from a repo is nice, I just wonder how stable it is or how potentially unstable it could be. |
| ||
| I can suggest few possible solutions for the issue connected with getting stable version of modules: 1.In ModMan modules list, we can specify SHA of stable commit and checkout it. It still requires git/hg installing, but solves the issue with unstable versions. 2.We can use public API of code hosting services for getting zip of different tags (which are tend to indicate the version). I know exactly that GitHub and Bitbucket provide such API. For example: https://api.github.com/repos/devolonter/flixel-monkey/tags https://bitbucket.org/api/1.0/repositories/swoolcock/diddy/tags Authors must set tags of repository. But in this case, it's not necessary to install git/hg. Also I don’t know if Google Code has similar API or not. This way also has another issue - folders with submodules will be empty. But it seems that I’m the only one who uses submodules, therefore I can refuse them. It’s just my 5 cents. Actually, I'm totally happy with the way ModMan works right now. |
| ||
| I like the idea of modman pulling a list of "packages" from a master repo -- this would allow centralized control of what shows up in modman while allowing us to use a repo system to maintain it instead of relying on everything hardcoded into it... the "packages" themselves, just being links to other repos, which I think would be best/easiest to upgrade by having modman pull from a branch on the remote repo that is specific to modman (allowing end-module coders to set the release schedule they want). Metadata could come in an expected format, much like Readme.md shows the frontpage on github. Good/bad idea? |
| ||
| As for "anything much more might require a separate maintainer", care to elaborate? I was under the impression that you were suggesting the "package up a release, send to Mark" kind of thing. That might get cumbersome for Mark. I think I see now what you're after now. Makes sense. |
| ||
| some one mentioned it above, why not have a medual manager on the site where members can upload their modile, give it a description fill out some details, give it a nice icon and bingo, a nice module list. Modman simply needs to look at that list for an upto date list of modules, this puts the effort on the module authors shoulders as they would need to upload their latest stable builds to this site. Mark said he wants to avoid that but I honestly dont see why, he must have some crazy bandwidth restrictions or something. |
| ||
| I like the Git/Hg/Zip idea. ModMan just needs a way to easily automate the download and installation of them in case the user requires them. Also, the list of modules could be set up into a repositoty too, so it can be contributed to accept addition, changes, etc. This decentraliced approach seems much more logical to me given the nature of Monkey than a site-based system. That said, it would be great to be able to cross reference the available modules in a rattings system, if this community gets big enough. Just my two cents. |
| ||
| I'm not sure I agree, I mean, I kinda do a bit, but I think the benefits of having a centralized module manager and system would be far greater than having it decentralized. When it comes to modules people tend to want reliability, stability they want to know that module is a release, they don't want to worry about using ModMan to update all modules only to have it break something in their code. Having a central manager/host here on monkeycoder would mean fewer updates, as authors would only push major updates to the site, this will mean a lot more stability while working with our code, when 3rd party modules are concerned. I think both systems have their merits, but I think having a managed , central list is a better option here, although that does mean a whole extra action required from the authors and more site work required by mark/simon. I wonder how other sites in a similar situation to us handle this, it's certainly not a new problem, im sure Unity centrally hosts all its modules, I think GameMaker does as well, although I hardly ever use those tools these days so I might be wrong. |
| ||
| If we had a central system, just thinking about Wordpress for a second and how it handles Plugins, it would mean we can rate a module and post a review or comments on that modules info page just like you can for wordpress plugins. I think having something like that would be really cool. |
| ||
| I made a Desktop App for a Module Manager in C# using WPF yesterday (so windows only), would be trivial to add mods if there was a list. Could even use the current login system, login using a browser behind-the-scenes and fetch a list of modules or help authors upload modules. Writing the php code to add a few pieces of strings & upload a zip and then list those in a list should not be more than a day's work, or? Don't even have to use a database here right? It would be enough with a text file for the module list and a ini/text file for each module that can be downloaded from the modmanager? I'm happy to give away the code and make it open source, but to finish it off I would need a list of modules that can be updated easily by authors. If it takes me ~day to setup a pretty fancy gui in WPF then could not an expert programmer (mark or someone on these forums) do a command-prompt manager (that Ted and other editor or module managers can use) in way less time? My view point is that those 2 days setting it up would result in tremendous value for all monkey users for all time. Or maybe I am missing some very time consuming part of this? |
| ||
| it's the maintaining the system which is the potentially tumultuous part of all this. People want automation but at the same time that implies that the work of combing through the modules and keeping up to date listings of them isn't simply passed off to either: 1. the module maintainer or 2. the module list maintainer. The arguments seem to stem over a few things, like ease of use, but I think the elephant in the room may simply be that some people aren't used to (or ready) to accept a version control system like Git into their lives yet. Personally, I just put all of the projects I look for updates for on my Star list and haven't looked back. Most people's projects probably do not need automatically updating their modules, especially considering that even with stable branches, there's a chance that method signatures have changed. I think maybe some people just want the illusion of convenience. A central repository for most Monkey modules already kinda exists, and it's Github. Star your favorite modules, and if you are ready to update one of them (ie: you're ready to refactor your code, or you don't have any code that will break by getting the update), then check out the page for the latest. Really, the best compromise for all of this has already been solved by other sufficiently mature code-sharing communities, long long ago. You have a package manager which is updated manually or invoked automatically from time to time to inform of the latest modules. Either we put the modules' code in packages directly to a master repo, or the master repo serves as the place pointing to where each module's central repo lives. The package manager is informed which types of updates are acceptable for the end-user to be presented with as "The latest" -- Stable (release), Unstable (latest), or backports to a specific version. What we use as the back-end to host these repos is only as significant as it is to maintain the hosting itself. Making our own version control systems in the name of 'convenience' seems a bit backward compared to the relatively minimal effort it would take to adapt an existing one (ahem, like Git!) to this sort of scheme. |
| ||
| To be more clear, this is what I'm after but for Monkey: http://getcomposer.org/doc/00-intro.md GUI is super simple to attach later. I'm fine if it uses GitHub repos to do the lifting, but not sure that is easier or simpler in any sense, I expect that complicates things. NodeJS has a very similar system. It is the process of: 1. installing (with dependencies) 2. updating 3. finding that is what gitHub does not provide. The fourth that gitHub does provide is the author's ability to push changes and I am mentioning that since it is probably useful to think twice before we exclude that and replace it with a person that acts as a "ModuleManager". And if my post above came across as we need to make a version control system, then that was not my intention at all. I think it is rare for module authors to not already use some form of source control. |
   |