Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os.nim Error: cannot evaluate at compile time: environment #5867

Closed
anthraxx opened this issue May 22, 2017 · 26 comments
Closed

os.nim Error: cannot evaluate at compile time: environment #5867

anthraxx opened this issue May 22, 2017 · 26 comments

Comments

@anthraxx
Copy link

Hi,

I'm trying to build and package nimble for Arch Linux using the latest nim 0.17.0 and it started failing with this version:

Hint: used config file '/etc/nim.cfg' [Conf]
Hint: used config file 'src/nimble.nim.cfg' [Conf]
Hint: system [Processing]
Hint: nimble [Processing]
Hint: httpclient [Processing]
Hint: net [Processing]
Hint: nativesockets [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: algorithm [Processing]
Hint: times [Processing]
Hint: posix [Processing]
Hint: ospaths [Processing]
lib/nim/pure/os.nim(802, 33) Error: cannot evaluate at compile time: environment

I'm a bit lost as I can't spot the problem when taking a look at the nim file. As this only popped up with nim 0.17.0 and seems to come out of the nim library files, i believe it may be an issue on nim's side.

@jasonrbriggs
Copy link

Same issue here (also arch). Rolled back to 0.16.0-2 and working fine again...

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

Here's what can reproduce it (Nim Compiler Version 0.17.0 (2017-05-22) [Linux: amd64] from the Archlinux community repo):

import os

echo "asdf"

Pretty annoying, any program that imports os should be affected, considering that the bug comes from that module, shouldn't it?

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

Just tested with a fresh nim compiled from the git repo, and everything is fine.
The problem comes from the Archlinux package.

@dom96
Copy link
Contributor

dom96 commented May 25, 2017

That's pretty bad, can we notify the maintainer of the Arch package somehow?

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

I found what's wrong. Presence of compiler.nimble in /usr/lib/nim/ makes the compiler stop and say the error message. Solution: remove it.

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

Bug now reported on Archlinux's bug tracker, with a patch attached for the PKGBUILD
https://bugs.archlinux.org/task/54184

@dom96
Copy link
Contributor

dom96 commented May 25, 2017

Please test this well, IIRC there is a reason for this .nimble file's existence. Also I don't understand how the presence of that file could possibly cause that issue so are you sure this is the cause?

@ghost
Copy link

ghost commented May 25, 2017

Affects me too.

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

I'm entirely sure removing that file makes the compiler work, I'm not sure what more there is to test.
For reference, the file compiler.nimble has this content:

version = system.NimVersion
author = "Andreas Rumpf"
description = "Compiler package providing the compiler sources as a library."
license = "MIT"

installDirs = @["compiler"]

requires "nim >= 0.14.0"

and is originally at the root of the Nim repo.

Here's a sample of the archlinux package buidling script for nim:

[...]
  ./koch install "${pkgdir}"

  install -d "${pkgdir}/usr/lib"
  cp -a lib "${pkgdir}/usr/lib/nim"
  cp -a compiler{,.nimble} "${pkgdir}/usr/lib/nim"
  install -m 755 lib/libnimrtl.so "${pkgdir}/usr/lib/libnimrtl.so"
[...]

That file just has nothing to do in /usr/lib/nim/, as that folder contains all of the things in Nim's ./lib/.
It just so happens that the ./compiler/ folder also gets copied in /usr/lib/nim/. That .nimble file is just in the way, not sure why.

You can probably test it out on your own system by copying that compiler.nimble file to where your installed library folder is (however I can't reproduce the issue by copying that file to the lib folder on a git checkout, using the compiled nim from the checkout).

@idlewan
Copy link
Contributor

idlewan commented May 25, 2017

You can reproduce it on non-archlinux systems like this:

  • have a Nim repo checkout
  • have a compiled nim somewhere (not in the repo checkout)
  • copy the compiler.nimble file from the root of the repo to the ./lib/ of the repo
  • make a file named test_os_bug.nim containing import os ; echo "asdf"
  • try to compile it with your compiled nim like this: nim --lib:~/path/to/your/Nim_checkout/lib/ c test_os_bug

@oceanborn2
Copy link

Hello, this also fixes the problem for me. I was importing os also.

@interfixus
Copy link

Me too. Also on Arch.

@Araq
Copy link
Member

Araq commented May 31, 2017

The compiler VM relies on stdlib.nimble to detect things like os.getEnv so it's not suprising things fail when the nimble file is not in the right position.

@dom96
Copy link
Contributor

dom96 commented Jun 1, 2017

Removing the compiler.nimble file might work but I bet applications that depend on the compiler sources will start failing. I suppose the compiler sources can still be installed via Nimble though.

@idlewan
Copy link
Contributor

idlewan commented Jun 1, 2017

What would make the compiler fail to import the compiler package if that compiler.nimble is not present ?
I don't see from the very little lines it contains what line is actually important for the compiler.

@Araq
Copy link
Member

Araq commented Jun 13, 2017

I don't see from the very little lines it contains what line is actually important for the compiler.

Its contents do not matter, it's its mere existance to cause things to end up in the "compiler" namespace rather than the "stdlib" namespace.

@frostRed
Copy link

I have the same issue on Manjaro

@anthraxx
Copy link
Author

@andreaferretti the current releases don't allow to simply kill the compiler distribution in the nim package. Doing so results in nimble not being able to build with system nim because of missing "compiler/ast".
If this is already fixed, when are new releases planned that solve this situation?

nim-lang/nimble#242
#4866

@andreaferretti
Copy link
Collaborator

@anthraxx I think you should ask to the mantainer of the Nim Arch package. This seems a packaging error on their part, it is not something that ca be fixed upstream

@anthraxx
Copy link
Author

anthraxx commented Jul 19, 2017 via email

@andreaferretti
Copy link
Collaborator

Are yo the packager of Nim or the packager of Nimble? As far as I understand from this discussion, the issue is that Nim is packaged incorrectly. This sentence

I don't see how this can be solved in a sane way on the packaging side while using system nim

makes me think you are only packaging nimble - not having control over "system nim". Am I understanding correctly?

@anthraxx
Copy link
Author

anthraxx commented Jul 19, 2017 via email

@idlewan
Copy link
Contributor

idlewan commented Jul 19, 2017

@anthraxx The fix is not to kill the compiler distribution. The fix is to remove just one file, compiler.nimble, that prevents programs from importing os. However, I just tried to compile nimble, and you're right that there's an error with that fix:
lib/nim/compiler/options.nim(1, 2) Error: module names need to be unique per Nimble package; module clashes with /usr/lib/nim/pure/options.nim

Solution:
Move the file currently at /usr/lib/nim/compiler.nimble to /usr/lib/nim/compiler/compiler.nimble.
Does that work for you? With that change, programs importing os can compile, and nimble can compile.

@anthraxx
Copy link
Author

@idlewan that finally sounds like a proper solution, thanks a lot for the efforts and investigation 👍 I will make extended tests and release new packages. If everything works as I expect it, i will close the ticket. Merci

@andreaferretti
Copy link
Collaborator

I am happy that works for you. The fact that compiler.nimble was out of place was already mentioned up in the discussion, so I had assumed you had no control over the Nim package to move it. Glad everything worked out in the end :-)

@anthraxx
Copy link
Author

@andreaferretti mentioning it dozen of times to remove it is not the same like mentioning to put it somewhere else where it makes both use cases happy. but never mind, it works now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants