Hi everyone. I've been in active development for my Mininim framework/library over the past month or so. In the process, I've gone through countless problems just dealing with inconsistencies, confusion, and overall frustration with the various package management solutions. So of course, I decided to write my own.
Percy (named after the greek hero that turned Atlas into stone), is meant to solve a handful of critical problems. That said, it's not complete yet, but I'd love to get some feedback. Please take a moment to look through the README on GitHub: https://github.com/mattsah/percy or, if you're feeling a bit bold, take it for a run. Right now by some miracle, it should be installable via nimble or you can install dependencies with atlas and build (then copy the binary). If you want to take a look at Percy and Mininim together, you should be able to get there in 4 simple steps:
nimble install https://github.com/mattsah/percy
percy init -w cb://mininim/app mininim
cd mininim
nim build
It should be noted that at present, it does not have a proper dependency solver, or really any dependency solving at all aside from a simple exclusion/inclusion during the graph build step. That said, I've built a number of other applications with it, successfully. I'm building most of the commands and other stuff around it first before I get to that as it's currently working for my use cases.
Percy came out frustrations with both nimble and atlas, neither of which do particularly well in early stages of dynamic development or seemingly with fast moving HEADs.
Sounds like Nimby would be a good match for you which is why I brought it up.
Now excuse me if I don't share much enthusiasm for "I build my own PM for Nim (which fails at modelling a dependency graph)" after the N-th time.
Percy came out frustrations with both nimble and atlas, neither of which do particularly well in early stages of dynamic development or seemingly with fast moving HEADs.
Why make your stuff a package at this point?
Nimby would not be a good match for me. Early development doesn't last forever, eventually things start to solidify, get tagged, and more consistently have proper versioning and need it as such.
Percy models the dependency graph just fine. It's the solver that's not in place yet. I've been at this for like a week and I'd rather make sure the usability and other major features like proper HEAD/branch tracking are in place.
The solver, for whatever my lack of experience in it is, is a known quantity, give a dependency graph, solve it. Given that Nimby is right on the broad requirement allowances of most packages, it already works without solving it and effectively only picking first versions for almost every project I've tried it on, which means I can test and get the CLI command and user experience correct, then swing back and plug in a functional solver difficult cases where actual conflicts are more common.