This is just the list on https://inko-lang.org/packages/ – which has a grand total of 14 packages. Even the text you quoted yourself says the package manger supports $any git repo, just that the website doesn't (yet).

In the Inko repo there are 13 contributors, with the #2 contributor having just 8 commits. The Website repo has 7 contributors, with the #2 having 5 commits. This is pretty much a one-person show.

But I guess every project, no matter how small the team, must support "my favourite VCS" and "do things my favourite way". Why don't you go and write a patch if Mercurial support or whatnot is so important for you?

This is the textbook definition of open source entitlement. You can't do anything without some asshole shouting at you for doing something "wrong".

Because PL devs and their communities, until very large, have limited resources; supporting niche use cases needs to be provided by people wanting that niche served, not by the primary contributors.

When did the ability to clone a repo outside of GitHub become a niche use case? It's not something you need to explicitly support, in fact you have to actively go out of your way to make sure only GitHub works.

Inko's package manager supports non-GitHub repositories just fine. What the original comment likely is referring to is the website only including GitHub based packages. This is simply because the script that populates that list hasn't been extended to support more than GitHub, because there hasn't been a need for it so far.

…Or use something generic like a tarball? Almost all DVCS have the ability to export an archive. Don’t build on lock-in; build on the generic thing… and then provide an ‘enhanced’ experience for something specific like Git or a specific forge.

When there are people using Inko and hosting their packages on another forge such as GitLab, and said forge has an API to get the data needed, I'll happily accept any patches to allow listing of non-GitHub packages on the website. The reason this hasn't been done thus far is simply because there hasn't been a need for it.

It is not even the worst I have seen. E.g. Kinesis and others sell keyboads with ZMK open source firmware, where official way to change key map is making github repository with a fork, editing it and using github to build it. I wish I was making this up.

So yes, seems like github has joined twitter and whatsapp as another thing the world works on.

> make them feel less supported or inferior?

Your point would have been much better made without the hysterical language

?

How should a developer who learned on & is happy with Pijul or Mercurial … or Codeberg, or whatever feel otherwise? There’s an implicit bias in supporting a much narrow band of tools, especially a proprietary one, that gets codified when not starting at something more generic. And if your projects aims to be long-lived it’d be equally myopic to assume Git will remain the most popular tool til the end of time. As noted in a sibling comment, had the project accepted a tarball, then almost any platform—past, preset, & future (assuming filesystems with files & folders are still used)—would be supported. A good example of this is what happens in Nix where the base is a tarball, and all shorthands merely a convenience DSLs that map down to the tarball.

I can't believe you replied after 2 days.

And why are you on another rant about tools and support thereof.

I was pointing out that your hysterical language was not helping your point.

You're not doing yourself any favours here