https://github.com/bung87/slim
hope this help you reduce your library dependencies when end user install.
task atask, "des":
requires "asynctest"
before test:
requires "asynctest"
This is at least the fourth Nimble replacement that has been developed by the community.
Maybe we should take this as a sign that the current state of Nimble isn't up to the community's standard ?
Maybe we should take this as a sign that the current state of Nimble isn't up to the community's standard ?
maybe this is a sign that nimble needs people to write PRs so we can improve what we have instead of splitting ecosystem.
splitting ecosystem.
I've never quite understood this argument - some changes require a different approach, specially when the existing approach is fundamentally broken with regards to a certain set of first principles.
Also, sometimes it's good to experiment outside of the status quo to arrive at an ergonomic solution _before forcing it on everyone else.
A fork is a non-coercive way to introduce these changes to the community giving everyone the a free choice, rather than forcing a change that some may welcome and some may not.
"Split community" in this sense means that the adherents of the original approach don't believe strongly enough in their solution that they think it will prevail, even with the considerable advantage of holding the status quo. If indeed the solution fits within the original repo, it's a trivial matter to port it back when its been proven to work - this is a win-win for everyone involved - this is how forks work "out there".
This is the same reason why the standard library should be a lot smaller than it is - it represents one view whose survival is not based on the merit or quality of the contents but rather on being a default that's hard to get rid of, stuttering development.
Instead of trying to create shame around experimentation, it makes a lot more sense in my book to embrace it, encouraging people try their ideas, and lowering the bar for getting access to these forks and libraries through tooling and community encouragement.
I've never quite understood this argument
The argument may not always be true, but understanding it is easy.
Here in Germany we had for a long time a big food discounter, which was not only popular because it was cheap, but also because it had a very limited set of items. Not a dozen soaps, coffees, breads, but maybe one to three of each. But all of good quality. Many people liked this over decades, as it made shoping easy and fast without a mental burden of many choices.
Or take regex. Ruby had one which is even part of the language, so ruby programmers use it from the start.
Nim has at least 3, with the confusing fact that two PCRE based ones are part of the STD lib, while the recommented pure Nim one is a separate packages. So I decided to just ignore all three til now. Or Nims 20 GUI libs -- I could not decide which one to use, so I started to create my own :-) (Well not really true, when I started with gintro in 2015 Nim had not already 20 GUI libs, I think it was less then 5 at that time.)
maybe this is a sign that nimble needs people to write PRs so we can improve what we have instead of splitting ecosystem.
Of course people don't write PR when there is a total lack of vision surrounding Nimble.
No roadmaps, no RFC, no communication at all. Questions regarding Nimble evolutions are left un-answered.
For reference here is the message I posted on discord asking about this :
Hello, recently with the Nim 2.0 post (notably with @treeform message https://forum.nim-lang.org/t/7983#50939 ) on the forum and the recent talk every 2 Friday there was a lot of talk of features missing to Nimble.
I know 2021 is the year to improve our tool and the package manager is a pretty important tool.
Recently, trying to progress on multiple SciNim packageI I regurlarly feel like I'm fighting against the package manager regarding :
* shared library installation
* dependency resolution and version specification
* Reproducible builds and lock file
* Projects that depends on multiple versions of the same lib are almost un-usable without un-ininstalling / re-installing every time you switch projects
* external dependency based on OS package manager (I know of distros but it's very limited)
Therefore I wanted to ask if there was an improvement roadmap planned for Nimble ? I think Nimble has room to grow and is holding package developer back for middle sized to big projects.
To this day, it is still left unanswered.
The impression that I get (and I'm sure I'm not the only one) iis that there is no ambition to have a modern package manager for the Nim programming language.
Nim has at least 3, with the confusing fact that two PCRE based ones are part of the STD lib, while the recommented pure Nim one is a separate packages.
Consider why though - many of the std modules are of low quality, and the only reason they get used is because they're shipped by default - this is a situation similar to an economic subsidy of a sub-par solution, in order to protect incumbents.
The low-priced chain with quality products presumably did not attract customers because they shamed the customers that were not going to that chain calling those that when to other chains community splitters - they simply opened up and created a better alternative.
I'm not looking to blame anyone here, but it's quite obvious that Nimble doesn't match the needs of the community anymore which is problematic for the official package manager IMO. And the problem hasn't been addressed so far.
There is a big PR that adds lockfile support to Nimble, we're reviewing it. The progress is not as fast as I would like, but resources are put into Nimble. About a "vision" -- well my vision of Nimble is reflected in the many RFCs that I wrote in Nimble's issue tracker.
I've never quite understood this argument - some changes require a different approach, specially when the existing approach is fundamentally broken with regards to a certain set of first principles.
Yes, some do. But not all and in this instance there is no reason to fork. The new feature fits right into Nimble and has already been given the green light in the relevant issues.
Of course people don't write PR when there is a total lack of vision surrounding Nimble.
No roadmaps, no RFC, no communication at all. Questions regarding Nimble evolutions are left un-answered.
Yep, I agree that we need a clear roadmap for Nimble. I think that would help the development a lot and hopefully spur some more investment from the core Nim devs.
I will try to get together with Araq and create one.