Spyhawk

Well, then this makes sense. I might not even be surprised if Squad got some money in the deal too. After all, curse is a business too.

I'm kinda disappointed that Squad added a direct link to Curse in the main UI of 0.25. KerbalStuff has done great progress, and is now so much better. Why not recognizing it as a very viable mod repository too?

Have you considered joining the common effort on that thread? The objective of this tool looks similar to what has been discussed.

I do understand your primary goal is to provide an alternative, open platform to modders (and I really prefer KS to curse!). However, modders want to distribute their work to users, so not focusing early on the distribution aspect is rather counter productive. But OK, it's actually in Beta and thus not yet ready for customers (modders/users) Edit: The new KS looks great!

Hmm, one of the strength of Python is forcing you to write readable code I also agree with the performance being not relevant here. I'd suggest to write a prototype in Python, and if performance are so bad that the app is unusable to recode it in C#/Mono. Pip?

Because the meta-data is just that, meta-data. It's the interface between the server side and client side of the "package management". Why would dull copies of licenses be there? Also, the licenses should already be included in the archives releases. It's not the package manager job to do the legal stuff if the upstream haven't done it properly (again, I see little value anything other than the .yaml/.json files with the bare strict minimum required to allow the package manager to work).

I was only referring to meta-data (the .yaml files). Licenses can be shipped in the archives themselves, or if needed included in a general dummy packages as done by Linux distributions. But please, not in the meta-data (apart from the license name).

Much better, thx! Will reread this summary tonight and might come up with additional comments. I'd even say a link is too much. Simply use the name of the license (like "license: MIT"), or for custom license, simply use "license: custom". If the user needs to know more, he could still check the mod forum URL, the mod archive, etc.

Seriously, man? About 50% of your posts are complaining about "I already said it before" and "I've explained it several times", yet you're unable to keep track of all the changes in a clear, simple manner in a post or reference document? No wonder it's difficult to follow you... Enough time to repeat yourself again and again, yet no time to put up a clear example in a concise manner? Seriously? Yes, I know this. The single reason I'm asking you to talk about the critical features only is that your brain goes in every direction at the same time, and you seem unable to prioritize. And I'm very functioning in the opposite way, because there's no way everybody could agree at some point if you start to consider everything at once! Better ask yourself what are the core features, document them in a simple and clear manner, and then talk about optional features and consider how they affect the already core features we'd agreed on. I really believe there's no point in having an IRC meeting right now, because having a meeting to talk about everything is pointless. It's the very same as talking about nothing. Please have an RFC first, that we can review before talking about it. On a side note, I believe IRC meeting are probably the less efficient method to achieve something, unless you have a clear agenda pre-defined. Yes, can confirm. You're pretty bad at planning in written form To be honest, I'm not sure I could bear with such personality on the long term - clashes will ensue for sure. Might be better for me to step down at this stage.

Yeah. It basically renders KerbalStuff useless from an user point of view. The fact that this feature hasn't been considered as a priority in the initial design somewhat blows my mind...

To be honest, you're really not helping by integrating all the optional, unnecessary stuff in your example repo. From what you've written in your first post, what you've included in your example repo and the various "optional" stuff you've talked about in this thread, you've lost me along this thread. My mind tries to find the ideal, simpler way to achieve the objective, while you're trying to integrate everything into this project at once, which personally confuses me It depends how you handle it. Packages managers usually keep track of a list of files that are installed by each package, while you're proposing to check if a file still belongs to a package, or if it has been overwritten since then (as I understand it, am I right?). I think a saner conflict management would use the former method. I'd suggest you write a clear document, with a short example and an example repo (or submodules repo) that doesn't integrate all the optional stuff you have in mind. To me, "optional" means "unnecessary". We could then talk about it over IRC. This part has been overlooked. Is this really not an option? Has it ever been tried previously?

A single checksum for the archive itself should be more than enough. That's the issue with repackaging. You'll end up forking and patching the mod to make them nicely integrate together, similarly to any Linux package management system. It's probably the fastest solution, but it requires quite a lot of work by the team maintaining the repo. Since the major issue is the lack of "standard" to package mods properly, and that Squad doesn't seem to really care, maybe the only viable solution here would be to work our ass off to make them recommend a standard, if enforcing one isn't an option. This idea has already come up in the past, but has it put into action? (pardon my ignorance on this subject).

Correct! There's libgit2sharp that might be exactly what is needed here. Gosh, why didn't think about this in the first place? I had more a single request for all files in mind, in order to avoid multi requests from the clients... Guess we'll have to live without it. I also see the GitHub API has a rate limit. Wouldn't this be a problem here?

(just a very quick answer, might expand answer later when I get time to do so) Thanks! That's exactly why your example repo didn't make sense to me in the first place. Yes, I did. But my concern about git is exactly the same as TeddyDD above. I do agree that git would be simpler and an effective solution for more advanced users, but I don't believe installing it on users machine is the correct thing to do for non developers. On the other hand, if github API allows easy access to the content of the json/yaml files that would be the perfect solution (not git software install required, no external database for a yaml/json interface). Hmm doesn't seem a direct access to content of yaml/json files is possible. So either git will have to be installed on clients, or the yaml/json file will have to be downloaded independently. Is there a better solution? Edit: Don't get me wrong, I like your idea. I'm just wondering if there's something more straightforward for a user point of view.

I understand this. And I still believe this doesn't belong to a "mod manager", as this is more a mod developer issue. There should be some misunderstanding here, because nobody has mentioned dependency resolution on the server side (only dependency metadata). Also, still don't understand how you got your DDoS. As long as the Json interface can provide info for more than a single package at the same time, you won't have a huge number of requests (just like the AUR and the client I maintain). My concern is unnecessary complexity for a still unborn project. As stated above, this is a non issue since git is decentralized by nature. It means mod B v2 conflicts with mod B v1 . If mod A can't be installed anymore because its dependency isn't available anymore, then mod A must be updated upstream or it will die. Note that I'm aware of people keeping many version of KSP in parallel, and I'm all for a feature in the client that switching from one install to another one, like some of the actual mod managers. But I do see this more as a copy/backup feature of the KSP install before any major upgrade, implemented in the client, for the KSP versions provided by Squad but not all of them (this is simply crazy to me). From what I've read, there was a Linux client but it is now deprecated. Anyway, Six-updater is not really documented, not platform independent either and does have a problematic license. I guess we can safely think about another alternative here. As of hosting, it's just unnecessary complexity again. I don't think a mod manager should provide a complete mirror service. Could you describe what you mean by "meta-data" here? The more I read you, the more I believe we're talking about different things and that we've never been on the same wavelength. From my perspective (and the one of TeddyDD that I can understand), there wouldn't be any binary distribution (apart from the compiled client itself), just a bunch of simple files that include basic information (name, version, download link, dependency information, etc.). Could you give an example on what would be on the Git repo (code, raw metadata file, mod itself?) and how the client would get access to that information? GitHub API is nice, but I don't see how to use it to make the relevant information available to the client.

Great. I extensively answered your post but lost all the content just before I could send it. I feel very lazy now but I'll do the very quick version instead: As long as you requires developers to jump in to succeed, I believe the project is doomed to failed from the start. The current situation is the main constraint, we have to make it work with what we have now. Unless Squad jumps in and enforce a specific way to create/packages mods, which I don't see coming any time soon. I was referring to the recreation of the local index from the raw-metadata files as "not the smartest way" of handling it since a Json interface and one single request as being enough to get the required information for updating purpose. Not sure how you manage to think about couples of hundreds requests and DDoS from there (you'd only need one request per level of dependencies across all the installed mods, which means about 3 if you have complex mods). Central repository. Yes, you can keep one central repo only. Since it will be using Git anyway, fork can be possible anytime if "something goes wrong" on the human side. Everything else is unnecessary complexity. Old broken links: Why should we care about them? Squad allows download of the two last KSP version, and by it's development model KSP is a moving target. Mods have to adapt or die. No point in supporting old versions of mods. I had a look at Six-Updater but the only relevant information I could find is that the license is problematic (CC BY-NC-ND). Haven't found what the Yaml/json interface look like. Could you provide a link here? Overall feeling: There's two conflicting views in this thread: The "meta-data" idea only from TeddyDD, and the more complex whole repository repackaging/hosting idea from yours. Obviously, I adhere to the former idea.

@TeddyDD: I've though about the whole search issue, and I realized that not allowing search from the start would be a major mistake. The whole point of a client software is to allow easy installation and upgrade. If the user can't install mods without browsing manually, he'd rather install mods manually too. Thus, an online index is required, which means you'll need to feed some database with the raw metadata. It also avoid client to implement this feature locally, which is certainly not the smartest way of handling it. @keks: I agree with most of you last comments. However, I really believe your list of requirement is too complex for this project to be successful (why those developer-tools? Why hosting complete mods again? Why allowing external meta-data repo, when you can just use a unique repo on github?). I'd keep the set of features as minimal as possible, and build upon it if required. As I see it, there's 3 steps involved here: * A meta-data format that can be easily written and maintained manually (through a dvcs like git). TeddyDD has covered this subject. * An simple online index that can return Json information to clients (or even other third party website!). Search, and detailed information of specific packages are needed. * A client software that use that Json information to download/check integrity/install with proper dependency management. The first two points are covered by software like the AUR. I'm currently taking a closer look at its code, but I'd say it does 90% of what would be required right now. The major issue is that it actually requires direct uploading of "meta-data" files on the server. Direct git integration is planned, but not yet implemented. This will be done in the next version of the AUR. Also, Arch Linux is a rolling release distribution and as such, managing multi-versioned software doesn't really make sense. As such, the available software are always the "latest" available. However, the AUR allows upload of various versions under a different name when the need arise. Those are mostly temporary issues anyway. Ideally, we'd have an index and json interface online as soon as possible, allowing the work to be done on clients.

Yes. If you want to avoid using an eternal website and provide only the individual json files, I'm afraid there isn't any other solution than downloading all the files and reconstructing a local database. I'd use "optdepends" instead of "optional". It would be much clearer what this field really is, since all of these field are indeed "optional". It is also what Arch uses so I'm already accustomed to it Lastly, I'm wondering about the requirement of including the version in the name file. I understand now this is to make the version available to client without downloading all files first, but to be honest I believe you'll have to do it anyway. The version number in the name file duplicates the one inside the file, and also makes it harder to update the json file when the mod is updated. Instead of simply updating the json file through github, you'll have to delete the file and create another one, making it harder to track change in a single file and not taking advantage of the ability of git to record only the difference between two changes.

I think the purpose of a "category" field would be to provide a pre-defined, limited set of options to choose from. A "keywords" or "tags" field might be overused and eventually be useless for search filtering purpose. Yes, a "conflicts" field would be very useful. You might think about allowing a "provides" and "replaces" fields too. Those 3 would be optional, but implementing them would ensure that any complex mod management operation that might occur in the future would be possible (ie, mod A requires dependency B, which is fulfilled by plugin B or C, or a mod X is renamed to Y).

TeddyDD> I would add an additional "Category" field to make filtering search a bit easier on the client side too. This should probably be an json array, to allow multiple categories (see curse.com). I'm also not sure if the "copyright" field is really necessary,as it somewhat duplicates the License field. Or maybe you're referring to an "authors" field here? If yes, renaming it might be wise. Overall, it looks good. I'm convinced this is the right step towards proper mods management.

You are right. If it is possible to achieve such a mod manager without an eternal server, then it should be done that way. The simpler, the better

Have you guys considered using something already existing? I'm an Arch Linux user, and that distribution provides a complete infrastructure for the Arch User Repository (AUR) where people can contribute "packages" (in fact "metadata" that will be used to build and install packages). It looks a lot like what you are trying to achieve here, with a Web Interface, a complete package description with dependencies information and a =dropbox"]RPC interface using Json that clients can use to download and install "packages". It also comes with a complete user management system, voting system (for popular packages), flagging system for obsolete packages. Instead of reinventing the wheel, adapting the AUR software to have a "Kerbal User Repositoy" (KUR?) would be simpler, and only effort would be needed to provide clients.