Hello! I am new to the community, but I am already in love with the language.
One Problem that I have encountered is that there is "package-rot". Since nim is a small(adoption wise) language, lots of projects are by a single author and at some point this author will stop updating the project. A Project that is not updated for one year frightens me - maybe unjustified, but I am sure lots of people will go to Awesome Nim -> nimgame2, and find it abandoned "2 years ago", then they are like: Is nim dead?
The strong-point of nim is nim itself, but the weak point is (at least from the newbie perspective) the package situation (rot, not merely existence). Btw. I have found plenty of tutorials, so the Tutorial-Situation is fine.
So I have basically a few ideas:
What about adding a feature to nimble (or small tool on top), that reads the git repos from the package repo and lists how old they are. Then add tags for categories and create a visual (f.e. html) output that shows how the package situation in each domain really is. This would allow a non biased, data driven view on the whole situation.
Sure there are enthusiastic nim-warriors; they could form a "package-squad" or "battery-squad" - and specifically organize the resource of nim coding time to the important breaches within the package-situation.
The squad can then create a website with most important contributions and packages to update - or to create in the first place. So there is a place to add to nim, without working yourself into the compiler, which most people don't like - since most people are not compiler devs (like myself - mostly web and simulation).
It would then help, if the package squad defines a "Battery-Squad-Package-Quality"- Standard, which is mostly documentation for __newbies__ (like me). I don't know all features, so if the documentation of the squad packages is very good and also explains more obscure language concepts where they are used - this would greatly increase the simplicity of reviving projects if the core maintainer goes away.
Another Idea would be not only including some examples, but lots of GREAT Examples, with documentation of some language patterns that are used - basically proto-Applications. So a focus on Examples for newbie-users.
A positive side effect would be that the usage of a "Squad-Package" would so advertise the great features of nim, which do not shine in a 20 lines example.
Over time this would build a number of packages, that are well documented and maintained, and would greatly increase the rise of nim (at least in my head this makes sense) - and the love and join for programming in the world.
Is there something like this already and I am to stupid to find it?
Is there a flaw in this logic? Do I miss some important aspects?
What do you think?
Personally I would volunteer as a member of the "battery-squad" if this discussion suggests that this whole thing might be a good idea.
Discoverability is a foundation of good package ecosystem, which is why I liked this recent announcement of this site:
I have used the github api and some crude scripts to get an idea of the real number of packages.
For now no metrics like how old is the project, how many commits at all, how many stars are applied, but there might be a lot potential for better sorting. Sth. like a value score, recency + number of commits + stars + author (has he more new nim repos, maybe - does he code in nim?).
Total packages: 2307
Github packages: 2185
Non-Github packages: 80
Non Git packages: 42
number of bad files: 50
number of parsed files: 2105
Updated this month: 2.3%
Updated in the last 3 month 8.5%
Updated between 3 and six month: 10.9%
Updated between last year and two years ago: 15%
66.2% of github Projects were updated at least one year ago
all projects longer last update more than 2 years ago: 1076 of 2105 51.11638954869358 %
number of projects updated this month: 50 of 2105 2.375296912114014 %
number of projects updated in the last three months: 228 of 2105 10.83135391923991 %
number of projects updated in the last six months: 458 of 2105 21.75771971496437 %
number of projects updated this year: 712 of 2105 33.82422802850356 %
number of projects updated in the last two years: 1029 of 2105 48.88361045130642 %
all projects longer than 2 years: 1076 of 2105 51.11638954869358 %
number of projects updated in the last three years: 1329 of 2105 63.1353919239905 %
number of projects updated in the last four years: 1579 of 2105 75.01187648456057 %
all projects longer than 4 years: 526 of 2105 24.98812351543943 %
I think at least I can try to make this analysis solid and searchable over the next days.
I agree with @PMunch that commit age isn't the best indicator of a "rotten" package. His termstyle came to mind when I read your post. This package hasn't been updated in 4 years what score does it receive?
Also, as I pointed out in the other thread that @nasi mentioned, stars as a value indicator could be penalizing to non-Github repositories. Of which there are many.
Something that's more alarming to me is the lack of "versioned" packages, only ~850 packages have a single version git tag associated with them.
Also, FWIW there are only 5 "non-git" packages and they are all deleted packages. The rest are aliases.
Not sure what the extra 2 you have in your scripts is from.
curl -fsSL https://github.com/nim-lang/packages/raw/master/packages.json | jq '.[].method' -r | sort | uniq -c
2268 git
5 hg
35 null
This makes sense. But for these kind of packages a "looked over by somebody"- label, or anything like this, would make sense, since a newbie don't know what is stable.
I guess stable packages with few changes are on average smaller packages, I currently build a analyzer for the package repo and try to add multiple ways of filtering it.
The endgoal for now would be to create a webpage where the filter can be used and also where people can add tags like "needs refurbishment", "stable" or "dead" to projects. And also tags for the topic. This would allow to see "package-tasks" for the community and would give people better orientation.
If you want some kind of metric, look in to lifetime/cycle of issues and pulls, number of issues and pulls, all versus size of code base. Complexity of code base, number of maintainers, numbers of committers as weight factors. But what does it all mean in the end? There's software that gets updates every 4-5 years and still has hundreds of thousands of users. Is it dead? There's code out there that just works.
„Verified to work with Nim: 1.4.8, 1.6.16, and 2.0.0”
That would be a nice to have.
Haha, the termstyle package was the module I had in mind as well. Just had a look and my oldest non-updated package drawille-nim and it still works just fine on Nim 2.0.0.
I definitely think something like what the Arch user repositories does with their "Flagged out of date" feature would be a better solution. Have a look at a package like oh-my-zsh-git for example, which shows the package as flagged and notes when this happened, when you click through you will also see a comment detailing why it was flagged. The author of course also gets a notification when this happens.
That's a big problem on nimble's end if so... because if I understand in demoing just now that is the ONLY way that nimble can satisfy a version check.
Meaning for example, I can't specify requires "weave == 0.4.9" because the only existing tags are 0.1.0, 0.2.0, 0.3.0 and 0.4.0.
I definitely think something like what the Arch user repositories does with their "Flagged out of date" feature would be a better solution.
AUR packages have a PKGBUILD or separate versioning which can become "out-of-date". The only valid "out-of-date" flag I think that would work for nim packages is a failure to compile with the latest stable compiler.
Have a look at a package like oh-my-zsh-git for example, which shows the package as flagged and notes when this happened, when you click through you will also see a comment detailing why it was flagged. The author of course also gets a notification when this happens.
I've seen some spammy use in the AUR with marking packages out-of-date mostly on the -git packages. Especially for something like a -git package that doesn't usually need to be updated frequently (unless build requirements change) the flag can linger for a long time, needlessly alarming users, when packages build just fine.
[OT] > I've seen some spammy use in the AUR with marking packages out-of-date mostly on the -git packages.
That's not spammy, just user too lazy too read the wiki. Which I can kinda understand. The VCS package case is weird enough, that it should be made more obvious to the user, not only the packager, imho. [OT]
Regarding nim packages, what does "out-of-date" even mean? Does not compile with latest Nim version? Which C compiler / version / OS?
IMO the only sensible approach is to leave this labelling up to the package authors, but give them a standardised framework to verify that the software meets certain criteria. E.g. templates for GH actions or Gitlab CI pipelines to run tests under the major Nim versions, OSes and compilers and badges, that show the status of these CI runs (which then should run regularly, ofc, and not only on the latest commit, which may be years ago.