Mirror of forum.nim-lang.org

13575 :: Percy: Yes, it's another package manager.

• mattsah (orginal) [2025-12-19T11:08:01+01:00] view original

  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
  Run

  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.

---

• Araq (orginal) [2025-12-19T12:17:42+01:00] view original

  Maybe join forces with https://github.com/treeform/nimby we don't need yet another package manager... :-/

---

• mattsah (orginal) [2025-12-19T15:02:29+01:00] view original

  I don't know who "we" is, but after trying all the others, I definitely needed another package manager, so I wrote one. Now I'm sharing it my progress on it. Would have been a shame if you stopped working on Nim after I'm sure many people said we don't need another programming language.

---

• Araq (orginal) [2025-12-19T15:22:56+01:00] view original

  But it's not clear at all to me that you needed another package manager. What does your PM do differently? Why not contribute to Atlas/Nimble instead?

  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.

---

• darkestpigeon (orginal) [2025-12-19T16:16:50+01:00] view original

  Hot take: most code doesn't need to be an "installable" package, package managers are overrated.

  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?

---

• mattsah (orginal) [2025-12-19T16:29:34+01:00] view original

  What my PM does differently is fairly well documented in the README. But I'll summarize it again here.

  1. It uses a hybrid centralized / local dependency model which means you have updating bare repo copies on hand (improving both performance and consistency)
  2. It uses git work trees to export the per-project dependencies to a local vendor folder (improving isolation and reliability)
  3. It tracks all refs consistently, so it can properly support both a require any that maps to HEAD as well as branch version like #main
  4. Given #3, it can also detect and update on things like forced pushes that overwrite tags.
  5. It actually only cares about URLs. The pitch that atlas uses URLs "internally" is broken for me, as it still relies on weird insistence on retaining limitations of Nimble package names, which also means they need to conform to identifiers, which has lead to package name conflicts and lack of namespacing more generally.
  6. Given #5, there's no need to compound or build up "pkgOverrides" in cases like moving a repository but still having old package names referring. Limiting problems with package rename and repository migrations. Your set package repositories are your source of truth for name => URL mapping, not what someone called the nimble file a year ago -- the only time you need an overload is if a repository with higher precedence overloads a package name => URL map in one with a lower precedence and you still want the mapping from the lower precedence repository, then you can map the package directly.
  7. Give #5/#6 you can create much more coherent and usable vendor structures, which for framework ecosystem development means I get to use a / in my package name, which means I get to have a nice single folder in vendor with all the packages related to that namespace.

  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.

---