Mirror of forum.nim-lang.org

9627 :: Procedure to remove modules from stdlib?

• templatedperson (orginal) [2022-11-17T16:52:30+01:00] view original

  Does Nim have a established procedure form depracating & removing things from the standard library? I'm asking because I just saw this comment in the v2 roadmap on github.

  It seems to me that removing JSON from stdlib entirely and moving it to a external nimble package is the way to go. You can then ask people to use that specific version of the package for backwards compat, slowly fix it and reintroduce it to the stdlib in a future release.

---

• arnetheduck (orginal) [2022-11-17T20:06:32+01:00] view original

  This is a problem with any module added to the std lib: you lose the ability to version it independently of the compiler and the langauge and there is no easy way to remove things that doesn't upset people - in general, the best way to help speed the migration of obsolete modules is to make the tooling surrounding package management easier and more stable (ie contributing to nimble or writing / maintaining a replacement (nimble has many problems that realistically / pragmatically only can be solved by breaking compatibility) - a good package manager allows people that want the old version to keep using it (since each version is immutable) and migrate to a new version at their own pace - everybody wins.

---

• DeletedUser (orginal) [2022-11-17T20:35:35+01:00] view original

  See https://github.com/nim-lang/RFCs/issues/473 for some discussion about this

  Nothing is standard so far. There is even a "parsesql" nimble package that is a diverged fork of the stdlib parsesql module, without the original commit history. And the stdlib parsesql isn't planned for removal or anything.

  There also seems to be a lot of back and forth and weird drama about standard library/distribution module moveouts in the past so I guess no one wants to do anything

---