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.