Use project IDs instead of slugs for dependencies
Closed this issue · 6 comments
Recently, a lot of modders randomly decided to change their slugs on CF and MR (for whatever reason) which is a breaking change for all release actions using mc-publish because it's using slugs instead of the project IDs.
Would it be possible to use project IDs instead since they don't change?
It should be already possible for Modrinth (ids and slugs are interchangeable in terms of their API), and, sadly, it won't be possible for CurseForge at all, since this amazing platform does not provide users with any reliable way to convert slugs to ids and back.
The project IDs on CurseForge are always numeric with 6+ digits, right? Wouldn't that be enough to differentiate it from a slug?
The differentiation is not a problem (also, I think CurseForge did not bother and just uses auto-increment numeric ids for the projects on their platform, so they are not necessarily 6+ digits long, but it doesn't really matter for the current discussion). The API requirements are.
For example, Modrinth does require you to specify project ids in your dependency list, but they also have a useful API method that can help you convert slugs to ids. Thanks to that, I can provide you, mc-publish users, with the ability to define your dependencies any way you want - from the most robust approach of specifying unchangeable ids to a more user- and accessibility-friendly way of specifying slugs.
On the other hand we have CurseForge, which is just a part of a small multimillion-dollar company, so, to be fair and balanced, we need to understand, that it is not feasible for them to create a public API for everybody to use in order to make their platform a little bit more accessible. The best thing we have (and should be grateful for!) is their CurseForge Upload API (please note that I cannot call it "publicly available" because if you actually attempt to use it directly from your machine, you will be gatekept by another small multimillion-dollar monopoly, that holds a fifth of the Internet hostage, named Cloudflare). As you can see, they require you to define the dependencies using their slugs, not ids, because this is one of the most logical thing to do on the API level (another one being defining your dependencies using their descriptions). Jokes aside, this is where the issue arises - as they do not have nice, clean, and publicly available API, I do not posses the ability to /reliably/ convert ids (which you would provide to mc-publish) to slugs, which are required by their Upload API.
Well, in the end, it's still CurseForge. It was worth a try. Thanks for the in-depth explanation and the funny answer. 😄
Let's leave this issue open, since, at the end of the day, I do want to see this functionality in mc-publish.
Nowadays CurseFurge has a thing called Eternal API, which could be used to convert ids to slugs via their Get Mod method, but there are some problems:
-
The method in question requires an API key (why tho?)
-
The API uses a different key than CurseForge Upload API (it would be weird and unintuitive to ask the users of mc-publish to provide two different keys for CurseForge)
-
It seems, that you need to apply for it (Sigh, welp, I guess it is better than paying $100 a month to be able to automatically post funny cat pictures online. But seriously, what's the matter with all these companies and their hate for public APIs?)
-
Their Terms of Use explicitly says that
Developer will moreover not demonstrate or provide Eternal to third parties or allow such third parties to perform any of the aforesaid actions.
So, I cannot include an API key into my code either, because of the violation of the said rule.
With all this in mind, the only solution here is to have a proxy API of some sort, which mc-publish could use without the (absolutely nonsensical) need of additional API keys. I won't setup it myself, since it would cost me money, and this project is a non-commercial hobby of mine (I don't even have something like Patreon, so the fellow users could support my work. At least not yet). And I have yet to learn of any third-party solutions with reliable uptime. However, I am open to suggestions.
Implemented in v3.3.