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

Dependencies with #head #135

Closed
davidsblog opened this Issue Dec 27, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@davidsblog

davidsblog commented Dec 27, 2016

At the moment, I cannot build Aporia with nimble, I get an error about version conflicts of the GTK wrapper. However, if I hack the aporia.nimble file and remove #head from the GTK2 dependency then it will build fine. So I'm wondering if the practice of using #head in a dependency is more likely to break? Would it be a more reliable build if dependencies always used a version number? Just a thought...

@dom96

This comment has been minimized.

Member

dom96 commented Dec 27, 2016

So I'm wondering if the practice of using #head in a dependency is more likely to break?

No... if you're using a bleeding release of Nimble then things are likely to break: nim-lang/nimble#289

@dom96 dom96 closed this Dec 27, 2016

@davidsblog

This comment has been minimized.

davidsblog commented Dec 27, 2016

Fair enough, I was just making a suggestion... But I haven't figured out where to find a stable release of Aporia Nimble yet, so perhaps I should do that instead :-)

@dom96

This comment has been minimized.

Member

dom96 commented Dec 27, 2016

nimble install aporia should work now to get you a stable release of aporia. Nimble grabs the latest tagged version by default, which is typically more stable than the git HEAD.

@davidsblog

This comment has been minimized.

davidsblog commented Dec 27, 2016

That's great! I've just done that and it has worked perfectly. I appreciate that.

Out of curiosity, is there such a thing as a stable release of Nimble (I'm using Nim 0.15.2)? I'm wondering if there is a better Nimble version than the one I'm using (I used the install_nimble.nims script from 0.15.2 to install it). I'm guessing that has given me the bleeding edge release of Nimble.

@dom96

This comment has been minimized.

Member

dom96 commented Dec 27, 2016

The stable release of Nimble is typically the latest tagged release. The install_nimble.nims script shouldn't install bleeding edge, please report that on the Nim repo :)

@davidsblog

This comment has been minimized.

davidsblog commented Dec 27, 2016

Cool. I will double-check versions from the install_nimble.nims and pulling the latest from GitHub just in case I've done something silly. But if the script does give me the same version then I'll report it. Cheers.

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