Why do this?
Questions for the community
I’m open to feedback and suggestions, including naming ideas for the org. If there’s enough interest, I’m happy to set it up and start maintaining the forks.
First question, the name of this github org? Second question, who wanna join this org ?
Is this approach acceptable from the Nim community’s perspective?
I think the general idea here of trying to maintain or patch libraries folks rely on is a good idea.
Are there concerns about redirecting Nimble packages to community-maintained forks?
I have some concerns about changing the url of nim-lang/packages depending on the scenario.
If supposing I use a stable (though maybe not "maintained") library I've assumed a level of trust from the original maintainer. If the source of this package changes without my knowing this trust feels broken. Particularly in a sense that given the decentralized nature of nimble and nim packages. One can switch to a hard fork by utilizing a full URL without nim-lang/packages NEEDING to change. I think for any package that is no longer active a good faith effort should be made to encourage original maintainers to "donate"" the source repo, for anything on github (which is most of the packages) this would make redirects more seamless, and following this we can make a change in nim-lang/packages.
If authors are entirely unreachable then I think more care should be given on a case-by-case basis whether a hard-fork should subsume a package name rather than just creating a new package (i.e. like pkg2).
I think the scenario I describe above is less murky if a package is completely deleted or unreachable which makes the original package name in nim-lang/packages less contestable.
Regarding a name for the org I think nim-community is available and the most clear.
Do you have examples of "important" libraries that are not maintained that would benefit from this treatment?
Is this approach acceptable from the Nim community’s perspective?
It honestly seems fine to me, the git repo for nim-lang/packages specifically states that having up-to-date packages is a requirement. The requirements section literally outlines "Non-compliant packages might be removed with no warning."
I think removing packages is a bit too extreme, but forking them and changing the URL to point elsewhere is fine enough actually.
Are there concerns about redirecting Nimble packages to community-maintained forks?
I think we need to establish a set of criteria for what exactly makes a package so "important" as to be community-maintained when abandoned, and nim developers should know about this when they submit new packages. (Put it in the requirements section of nim-lang/packages)
As @daylinmorgan outlined, you do risk breaking user trust when you switch the source of a package, so we need to establish a transparent process for turning packages into community-maintained ones. We need to be able to take advice from users, we need to give time for the original package maintainers to respond with any objections (if they have any)
With regards to technical concerns, I have very little. This isn't very different from just releasing new package updates. There are probably going to be users out there who have configured their dependencies to always use the latest version of any given package, and so, I am worried that some software might secretly break because of it. But that will always happen, and the only thing we can do is to encourage users to depend on specific package versions or use lockfiles.
Would it make sense to treat this as a semi-official “community maintenance” org?
Yeah, that's basically what it is. The nimble package repository is hosted on the official GitHub organization, and so the community maintenance org would be at least semi-official, since packages can be re-pointed to the community maintenance org.
+1 to @daylinmorgan's suggestion about creating new packages instead of switching the URL (pkg2 instead of changing the URL of pkg).
We could also just use a prefix (pkg-community or pkg-public), I believe in this option because it would preserve user trust and also let the original maintainers keep control of their package should they return.
Though, we might have to introduce a way to mark a package as abandoned and signal to users where the new, community-maintained package is. I don't know if tags and package aliases are flexible enough for this (I don't think they are)
my intension is make the repo into a well maintain status,I'll not touch nimble and any other package manager tool, so change package installation dir is not on the list, I created the org named as nim-community
and here is the first issue https://github.com/nim-community/tools/issues/1
If you will allow me to be a doomer for a bit, I don't know if doing this is an actually good idea. I am aware that "slippery slope" is a fallacy, however in most cases centralization like this tends to lead to situations like Nix/NixOS, where the "Nim Community" is represented by:
The NixOS Foundation Constitution The NixOS Foundation Board Members The NixOS "Steering Committee" The NixOS "Moderator Team" The NixOS Code of Conduct
as if a person is not a member of the supposed "community" unless they strictly acknowledge this strict social hierarchy. The Rust "community" is another such example, etc etc. The idea being that there is a unified community and culture behind such a global project as a "nimpkgs" or whatever is to me personally extremely culturally american, aka extremely blindsighted.
On top of that, calling it "nim-community" again implies that to be a member of said community you need approval (by whom?), and that you need to adopt the social structure and culture expected by said "community".
I do not agree with setting this as a way of preferred existing within the actual broader nim community (this forum, matrix, irc, telegram, etc etc.). I also do not agree that we should allow people to have authority over who is a maintainer of a package or not. Me deciding to be a maintainer of X package, only to be removed because I do not conform to a theoretical "culture" should not be possible, and I do not want no-coders to have any say in how I perform my duties as a package maintainer.
Now that this is out of the way, specifically on the idea of adopting abandoned projects into a single repo and reindexing them on nimble, I think there is absolutely no need for this. People can fork a repo, get consent from the original developer and then both of them could send a notification to the nimble repo to update the URL. At the same time I do not mind abandoned projects. New projects do take their place and this moves the ecosystem forward, since new projects don't reinvent the wheel, but they do have a "fresh rewrite" aspect that tackle many issues that were difficult for the older version to fix, either because of backwards compat, or technical debt, or whatever.
In any case we will see how this develops, hopefully I am wrong and this helps the nim ecosystem without relegating it into another nix-community.
I get your concern about community organizing and the theoretically fraught social dynamics associated with it.
I think comparing it to NixOS is difficult given the difference in scale (both in terms of users and in terms of infra/packages).
One concern regarding "abandoned" projects besides continued maintenance is also the lack of caching for packages (FWIW I don't think it's really worth the burden associated with storing and maintaining package sources like PyPI/crates.io/npm).
One prominent example of this already is https://github.com/nimbackup which has several repos from a former nim user that deleted their github account.
New projects do take their place and this moves the ecosystem forward, since new projects don't reinvent the wheel, but they do have a "fresh rewrite" aspect that tackle many issues that were difficult for the older project to fix, either because of backwards compat, or technical debt, or whatever.
I think this position implies there is ample development resources for all problem domains to replace abandoned packages, but the nim community is small. When something like a simple patch is needed to make it compatible with a newer version of nim, but the original author has moved on, it would be nice to have an obvious place for pooling developer resources.
Me deciding to be a maintainer of X package, only to be removed because I do not conform to a theoretical "culture" should not be possible, and I do not want no-coders to have any say in how I perform my duties as a package maintainer.
I think this position is fair and emphasizes the need to fork (and rename) rather than adopt existing packages (when the consent of the original owner is not available or given).
---
Correct me if I'm wrong but I think that @bung is not imagining anything more formal than a place to keep active projects they and others might need that have been in neglect for an extended period of time.
+1 to @daylinmorgan's suggestion about creating new packages instead of switching the URL
+1 as well - hijacking package names has lots of problems - just change the names and users that want to migrate, can migrate.
As long as the fork has a new name, there's really nothing wrong that can come out of it - then it doesn't matter if it's nim-community or an interested developer doing the fork.
A presumptive nim-community could, to solve the naming question, simply add _community to the package name they're forking, to have the name cookie and eat it.
@daylinmorgan I think comparing it to NixOS is difficult given the difference in scale (both in terms of users and in terms of infra/packages).
Yes, but I would like to avoid a situation where we set fertile ground for these behaviourisms as the language and the userbase grows.
@daylinmorgan I think this position implies there is ample development resources for all problem domains to replace abandoned packages, but the nim community is small. When something like a simple patch is needed to make it compatible with a newer version of nim, but the original author has moved on, it would be nice to have an obvious place for pooling developer resources.
My main point regarding this specifically, is that the language and the user base evolves and focuses on different things as time goes on. This to me is a natural evolutionary process of the language, and the ecosystem around it. Libraries that are abandoned might be abandoned for many reasons, but if they are abandoned because of technical debt, then they are not worth maintaining imo; let them deprecate naturally and if there is need for a library, parts of them can be reused. If on the other hand they are abandoned because the main dev decided to move on, then another person needs to pick up the project and keep it running. In either case, having a centralized org for this does not solve neither project's issue. The fact that the repo got forked does not mean that anybody will pick it up, who wouldn't have picked it up in the first place. A centralized org only works to tell people "hey, we forked this repo, we need a maintainer for it.", it doesn't guarantee that a maintainer will materialize; for this though we don't need a github org, we could have simply an announcement, or a board, or a mention in nimble that the package is unmaintained.
@daylinmorgan Correct me if I'm wrong but I think that @bung is not imagining anything more formal than a place to keep active projects they and others might need that have been in neglect for an extended period of time.
I don't assume any malice on part of @bung, but I do think that it was a mistake on their part to name it nim-community. My biggest gripe is the implication that having this name suggests that the specific github org is the "community".
In general I don't see why, if somebody picks up an abandoned package, they can't just raise an issue tagging the original maintainer. There could be a process regarding this without the need to invent new centalized social constructs.
@Araq Switching the URL is established practice and arguably why you typically only list the package name in the .nimble file and not the full URL... packages.json is the source of truth here where to get the most recent package of name X.
Essentially this
I don't think that having a centralized org fixes package deprecation, since having an org doesn't guarantee having a maintainer.
In practice I imagine the order would be:
In general I don't see why, if somebody picks up an abandoned package, they can't just raise an issue tagging the original maintainer. There could be a process regarding this without the need to invent new centalized social constructs.
I think this highlights some of the motivating issue which is that folks are sometimes not keen to respond at all (choosenim had many open issues/PRs, until it was finally forked to nim-lang/choosenim).
And I agree there isn't much practical difference between nim-community/pkg-community and <nim-user>/pkg2.
Maybe most of the concern here would be ameliorated by @bung selecting a different name than nim-community (which was the name I suggested, sorry). Thus negating some of this original sentiment:
Would it make sense to treat this as a semi-official “community maintenance” org?
FWIW I don't think there is a long line of folks trying to deal with technical debt in pre-existing libraries.
---
Feel free to ignore this as it's mostly just me being cheeky and semantic but I'd say establishing a "process" would be codifying an agreed social construct of how to resolve names to urls by community tooling (nimble, atlas).
I'd be all for improving documentation on the process for name/url changes in nim-lang/packages, so that expectations are clear for contributors.
First, it seems to me that request is collaborative rather than adversarial as someone to have appeared to insinuate.
Second, Nim arguably gained some of its popularity from having a relatively comprehensive standard library. However Nim does struggle with a relatively small set of well-maintained, libraries. Given that reality, any serious effort aimed at improving availability, maintenance, or continuity is great way to make the language available to larger, less advanced audience like myself who is not interested or have a skill to understand/evaluate/fix any issues that arise from using stale code.
Finally, for the sake of clarity and continuity, forking the relevant projects, as some have already suggested, seems like the cleanest path forward. It would reduce ambiguity around ownership and versioning.
First, it seems to me that request is collaborative rather than adversarial as someone to have appeared to insinuate.
Kindly refer to me by me if possible, saying "someone" serves no purpose but to marginalize me, and worse marginalize my opinion. Also kindly don't act as if I said things I didn't say. I clearly said
I don't assume any malice or any deeper intentionality on part of @bung, but I do think that it was a mistake on their part to name it nim-community.
I also clearly didn't in any way shape or form say that @bung is acting is an adversarial manner. If you think I did please show me the quote. I only insulted the idea by calling it american, which I stand by. The intentions being good doesn't minimize the potential for a bad outcome, (as we have seen countless times), nor do they stop a good thing turning bad.