Package request: nim-2-0

[xTrayambak]

Project description

We currently package Nim 2.2.0 since this PR. However, there are some glaring problems with Nim 2.2.x for now:

• A lot of packages are outright broken due to changes to the type system (eg. sigui)
• A lot of packages that do end up compiling have issues, like nimlsp completely maxing out the CPU.

I think we should package Nim 2.0 as a separate package for some time as the Nim team irons out these problems, similar to how there are multiple versions of NodeJS in nixpkgs currently.

Metadata

• homepage URL: https://nim-lang.org
• source URL: https://github.com/nim-lang/Nim
• license: BSD
• platforms: Linux and Darwin

---

@ehmry @Eveeifyeve

Add a 👍 reaction to issues you find important.

[Eveeifyeve]

Project description

We currently package Nim 2.2.0 since this PR. However, there are some glaring problems with Nim 2.2.x for now:

* A lot of packages are outright broken due to changes to the type system (eg. [sigui](https://github.com/levovix0/sigui))

* A lot of packages that do end up compiling have issues, like [nimlsp](https://github.com/PMunch/nimlsp/issues/180) completely maxing out the CPU.

I think we should package Nim 2.0 as a separate package for some time as the Nim team irons out these problems, similar to how there are multiple versions of NodeJS in nixpkgs currently.

Metadata

* homepage URL: https://nim-lang.org

* source URL: https://github.com/nim-lang/Nim

* license: BSD

* platforms: Linux and Darwin

@ehmry @Eveeifyeve

Add a 👍 reaction to issues you find important.

Yeah I agree with this and I will look into making a pr that will fix this by separating nim 1 & nim 2.

[Eveeifyeve]

But I think I might go the generic approach simular to how pnpm is doing this where there is two packages nim & nim_1

[Eveeifyeve]

But also can you provide like a btop or something that shows that nim 2.2.* is the problem.

[Eveeifyeve]

But most likely I would wait for a response from PMunch/nimlsp#180 to see if it's a nim problem and not a nix problem. I would highly suggest reporting the high cpu usage here that way nim can work on a fix for it.

[ehmry]

Nim-2.0.4 is still the default Nim-2 on the release-24.05 branch so we should sort this out before 24.11 (#344920). I would prefer just to fix everything that we have packaged so that it runs with 2.2.0.

[Eveeifyeve]

I mean first of all the high cpu usage is not nix problem it's either nim_lsp or nim itself problem and two packages broken? Can you please send a hydra log of a package that is broken so I can deep dive into the issue

Nim-2.0.4 is still the default Nim-2 on the release-24.05 branch so we should sort this out before 24.11 (#344920). I would prefer just to fix everything that we have packaged so that it runs with 2.2.0.

And second of all this might be a blocker, but I can't confirm until you provide hydra logs. And confirm it's a nix problem (not a nim problem)

[Eveeifyeve]

And I would if I was you make an issue to sigui to tell them to update their types as there has been changes to types that they should be aware of.

[Eveeifyeve]

And I would if I was you make an issue to sigui to tell them to update their types as there has been changes to types that they should be aware of.

https://github.com/nim-lang/Nim/blob/version-2-2/changelogs/changelog_2_2_0.md#changes-affecting-backward-compatibility

[xTrayambak]

And I would if I was you make an issue to sigui to tell them to update their types as there has been changes to types that they should be aware of.

I've already notified the maintainer of it.

[xTrayambak]

But also can you provide like a btop or something that shows that nim 2.2.* is the problem.

The thing is, this CPU usage problem became much more frequent after 2.2.x, so it might be the result of an undocumented change in an internal Nim component (my educated guess would be the GC).

It's best that we push out a Nim 2.0 package before 24.11 enters feature freeze.

[ehmry]

And I would if I was you make an issue to sigui to tell them to update their types as there has been changes to types that they should be aware of.

I reported the issue with Sigui at Shady, because that is where the type that breaks for me originates: treeform/shady#21

[Eveeifyeve]

But also can you provide like a btop or something that shows that nim 2.2.* is the problem.

The thing is, this CPU usage problem became much more frequent after 2.2.x, so it might be the result of an undocumented change in an internal Nim component (my educated guess would be the GC).

It's best that we push out a Nim 2.0 package before 24.11 enters feature freeze.

I mean yes but a simple fix can be making an issue downing on the problem to ninlang or ninjas because it's not a nix problem but how nimlang or nim works.

[Eveeifyeve]

I mean I will start working on package for nim 2_0 but I am going to add a throw to say it will no longer supported until the issue in here are fixed just as a temporary fix.