Let me start with an example: I wanted to build a graphical bitmap of a font with the basic ASCII characters for some retro testing development. Still learning Nim so these projects are easy and fun to work on.
I wanted to use a specific mono spaced font, so I downloaded a TTF and wanted to render it on a bitmap. In C++, I used stb_truetype, so I went on and did
$ nimble install stb_truetypeBut all the functions I wanted to use, are not yet implemented. The developer says so himself: https://github.com/guzba/stb_truetype -> These bindings are not complete. Contributions are welcome!
Luckily, I saw that there is a fork. This fork has the functionality I want to use, but that developer gives the same message. But this library is not on the official nimble list, so can I trust it? (in this case, I am quite certain that I can, but that's not the point) I got it to work with this library, but it has some weird quirks. For example: the getCodepointBitmapBox proc returns a cstring, while the original C code of that function does not return anything. If I inspect this string, it is always empty on my set of calls. I don't know why it returns the cstring and what it should contain in what case. No problem, I just add discard before the call and ignore it.
Why was this code base forked anyway? Why were these added functionalities not contributed to the official package?
But... more and more, this feels like something dirty: I have to use an unofficial nimble package, which is incomplete and has quirky code. I could go and write my own implementation (I need to learn this first, but definitely want to - more and more), but this should not be the way, right?
I assume what I am describing is happening to lots of packages, official or not.
So how do you guys handle this?
It's not a Nim specific problem. It's GitHub. It's not a coders community, it's (has become) a dumping ground for code. The beautiful idea that a passer by contributes is a folly. Also the idea that you can there create a community around your work does not work. Pure users have nothing to contribute but bugs and complaints. There's 'no' user coder interaction.
GitHub is a "silo" and rather anonymous. Would you host incomplete, half baked code on your own site, next to your resumé? Would you put code up there you can't, won't, will not maintain?
I understand and I think I agree.
But... how do you then handle it? You only use your own wrappers and don't use external ones?
But this library is not on the official nimble list, so can I trust it?
In general you shouldn't trust any external library, whether it's on any list or not. If a library is popular or it's author is reputable - good chances everything would be fine, but it's never 100%. And it's not specific to Nim.
Why was this code base forked anyway? Why were these added functionalities not contributed to the official package?
We can only speculate, but most likely it's either: author of fork planned to PR changes and then lost motivation or wanted to overtake the development of bindings and lost motivation or just made a couple additions to make it work for his own project.
but this should not be the way, right?
You might have a better experience with Futhark - https://github.com/PMunch/futhark It's a tool that generates complete bindings to C libraries automagically.
You might have a better experience with Futhark - https://github.com/PMunch/futhark It's a tool that generates complete bindings to C libraries automagically.
Thanks for the link. Like I mentioned, I need to learn to create my own bindings yet, still in the process of learning Nim. It feels like I should give this some priority...
But I get the feeling that it may be usually better or wiser to simply create all bindings yourself (and then maybe contribute them if they are actually good)?
Nimble index needs cleaning of missing repos.
Yes, so it seems.
I am totally in love with Nim itself, but at this point it feels like the Nimble index should be cancelled or managed by someone (which you can't expect from anyone to do for free). But the way it is now gives newcomers a false feeling of it having support for lots of libraries like it is in for example Python pip (where there are also bad packages, I know, but most of them are fine).
Sorry as a hobbier I can only say these useless things.
No, you're right. We can only all try to contribute to make Nim as big as the others. The sad part is that those other languages usually have companies behind them pushing them upwards (and not always doing the language any good on the long run).
I just hope Nim won't get out of the picture because of all this competition, because imo. it is the best designed compiled language I've ever seen.
You might have a better experience with Futhark - https://github.com/PMunch/futhark It's a tool that generates complete bindings to C libraries automagically.
I just tried this and it works like a charm! I replaced both stb_image and stb_truetype with this, had to rewrite the code a bit (lots of ugly casting and things like that), but it works.
Now it's up to me to write a wrapper to get rid of all the ugliness I guess.
I just tried to do a wrapper without futhark, with {.importc.} and things like that, and that worked good too.
I think I prefer a method with less dependencies, so I may stick with that, but we'll see :-)
Thanks for all the great answers guys!
This is such a strange post. Do you think nimble is like some kind of App Store? It seems to me like you have no idea what open source even is. The most common open source license is probably MIT, and basically all include "there is no guarantee any of this code works for any purpose at all".
Why was this code base forked anyway? Why were these added functionalities not contributed to the official package?
Anyone can fork anything at any time for any reason, and there is no requirement to upstream anything. Nor should there be. If you think there should be, please explain how you'd like to enforce this and what the penalty should be (fine? prison? banning?).
Also, what exactly is an "official package"? Unless it is in the language's standard library, you are completely at the mercy of the completely free effort of others. Whinging or support for it is such a strange thing to see supported in a niche language's community.
Also, what exactly is a "finished" project / libarary? I've never seen one. Nim isn't finished. Rust isn't. Zig isn't. Hell C++ isn't. Let alone random open source libraries.
I think you just expect that someone else has done all the work for you and wanted to whine that this isn't true in Nim. Well guess what? Nim is not as popular as the language you're coming from so you can't count on the immeasurable free effort of others you've taken for granted.
It is polite for projects to explain the state they are in. Unfinished projects are incredibly valuable as a resource to learn from.
The notion no one contributes is also false. Even if it is rare, it happens all the time. Again though, it happens in proportion to popularity, so Nim libraries are at a disadvantage vs JS or whatever.
Would you host incomplete, half baked code on your own site, next to your resumé? Would you put code up there you can't, won't, will not maintain?
Hell yes I would. I utterly disagree with this and it pains me to see.
Hiding your code and using excuses like "half-baked" or whatever is just fear of judgement or laziness or whatever. Why couldn't someone benefit from seeing your approach and deciding to take the good from it for their own attempt at some functionality?
Some people have this idea that open source means "a perfect library I can use for free" (not caring at all about the literal openness of the source). This is not the valuable part. The value is in "I can read how others have worked on this and learn from that to do better".
Also the stb_truetype bindings stuff is so easy this whole thing is making a mountain out of a mole-hill.
Ok, this was just a question about how others handle the nimble packages. This was not at all a rant or whatever. Some answers made good points, but nothing (coming from me at least) was meant as negative or generalization or whatever. The example stb_truetype was simply an example to make a point to base my question on. I never intended to make any mountain out of a mole-hill.
I do not expect anything from anyone, I just wanted to know if I should do it myself or not (or even more if I was missing some obvious things I should have known), if there was someone who manages the packages so that if I want to contribute I contact him, etc...
I have always been someone who did everything myself, the number of third party libraries I have ever used can be counted on two hands and I have done lots of projects. It's how I grew up with computers in the 80's. I am simply trying to learn Nim and trying to find out how to approach it best, what to lean on and what not to lean on, what to trust and what not to trust, ...
I am not going into this any further. There was no negativity at all intended.
Safety and integrity of packages is (or should be) a valid concern. This accident happened before 90% of internet was malicious:
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code
More recently, browser plugins are being turned malicious after becoming famous. Same mechanism could be utilized in nimble packages:
https://thehackernews.com/2023/12/new-report-unveiling-threat-of.html
IMO, this is one of the main reasons against shrinking the standard library - increased chance of malicious code while having zero mechanism to protect nimble users from malicious packages. I
Given you've mostly done things yourself, I suggest something like this:
Find one or more open source libs you want to use. Then either use them directly from nimble (requires "libname" shorthand) or fork them and use requires "fullgiturlpath" as pointed out by Araq above).
In the case you use the nimble short name, you're trusting the maintainer of that lib to both not break your stuff and to not do anything bad. I worry more about breaking my stuff personally, but bad things is equally valid.
I suggest not being opposed to making a personal fork to ensure it remains the way you left it, then you can pull from upstream whenever you want. I don't do this for everything but its a pretty good idea imo.
Hi @scippie
I would suggest that you go with the personal repo and potentially the package-version in your repo for production projects:
I had some trouble with nimbledeps due to working with Nim v1.6.18 and v2. That was solved by setting the nimblePath in the config.nims:
when NimMajor >= 2:
switch("nimblePath", "nimbledeps/pkgs2")
else:
switch("nimblePath", "nimbledeps/pkgs")
To activate the nimbledeps just:
$ mkdir nimbledeps
$ nimble install <package name>