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 buildIt 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.
Why make your stuff a package at this point?
Easier re-usability cross project. I'm literally working on frameworks and libraries for other developers. Languages with good package ecosystems and tooling around package management grow and thrive. It can attract less experienced developers when things seem to "just work" with a few simple commands and they don't have to follow a 20 page instruction manual to download and integrate a library.
"Hot" is not the word I'd use for that take.
Languages with good package ecosystems and tooling around package management grow and thrive. Well, npm does grow and thrive, but I'm not sure a cancerous tumor growing and thriving is something to be celebrated. And I suppose some people do enjoy python dependency hellscapes...
things seem to "just work" I had an impression the lesson of things seeming simple was actually learned after the clusterfuck of frontend frameworks. But oh well...
Easier re-usability cross project. don't have to follow a 20 page instruction manual to download and integrate a library.
What kind of other wonderful dichotomies do you have in store? Writing javascript vs handrolling assembly?
Clusterfuck ecosystems although it may be correlated to package managers, is not caused by them. That said though, the fact that I can't see a clusterfuck cause I need massive domain knowledge specific to every project and the dependencies it pulled in manually and integrated doesn't mean those things aren't also a clusterfuck, and worse than a clusterfuck, completely inefficient.
NPM sucks. From what I can tell Python packages suck, although have gotten better. Last I checked pretty much everyone loves crates, and, personally, I come from the PHP world which is the example (in my opinion) how package managers (when done correctly) can actually fix the clusterfuck and improve the ecosystem as a whole. Composer is a package manager that "just works" (IMO), and Percy is heavily inspired by it.
Prior to composer, pretty much everything in PHP was spaghetti. 10+ years later, there are more common standards, shared interfaces, best-in-class packages which have risen to the top and are uniform across the "industry." You have major adoption of large (modular and monolith) frameworks, etc. That doesn't mean people are doing stupid shit like creating a package for left padding. It does mean, however, that PHP is considered wildly approachable (even if you dislike it as a language).
Why? Is your framework hundreds of megabytes in size? If not, what's the problem?
There are lots of problems, but clearly our needs are quite different, so I'm not going to keep explaining to you why package managers exist in the first place. People didn't just create them cause it was something fun to do. They solve a real problem of distributed modular code that can be used independently or in combination, can change hands (i.e. bits an pieces be passed along to other maintainers), can run isolated testing, can be separately or independently deprecated, can have separate/distinct documentation, and on and on and on.
The cognitive load for a mono-repo the size of any modern framework alone is good enough reason not to throw it all in the same folder.
As for your other suggestion, which basically just amounts to doing package management, but manually... I'll pass.
I like things specialized and concrete.
Cool, now you're getting it. We like different things. Have different wants and needs.
But we didn't get that far. Unlike Araq, you're actually having the conversation. If he would have responded like you, you may have gotten a "welcomed contribution" out of it. Instead, you got me writing a "fix" in my code and a hesitancy to "contribute."
Yout bug report didn't convey competence and so I was overly harsh, my bad, my loss. The next time explain your use case somewhat so I can see you're not some script kid with an attitude like "it's unintutive for me and I'm a genius and so there is clearly a bug here, no matter how many people used it successfully before me and I cannot bother to read the code or look at the data my program produces".
To @araq's point a project like Nim get's tons of crappy issues filed. Without previous context or a history or reputation issues without much context or details will often be closed or ignored.
There is a bit of art and learning to making good issues and PR's and to get responses. Even then it can sometimes take a bit of persistence to raise attention. After all even with AI's and LLM's attention is a rare commodity.
Well, judge for yourself: https://github.com/nim-lang/Nim/issues/25331
I don't think I gave a ton of context, and admittedly, I only went as deep as XmlParser when I first submitted, which was looking at xnEntity and returning the entity node type, but, I don't think there was anything overtly off about the issue. I even suggested "should be?" in paranthesis in the expected behavior (again, based on XmlParser itself). The "special case" occurs in parsexml.
I thought about reopening it, and asking "why is it a special case?" But given that the answer Araq gave here was: "Dunno, it just made sense to me this way" and how I've seen him respond historically, I didn't bother.
He could have also responded in the issue by saying what you said, but, as he might say his response didn't convey competancy and even if it was originally implemented to be specifically DOM2/3 compliant, it was instead "just made sense." So I guess we're all just coding on vibes here.
As I said, I appreciate your answer and the clarification around DOM2/3. I would just add that there's a distinction that should be made around "expected behavior based on existing code" which one may call a proper bug, vs. simply "expected behavior." Open source projects seem to thrive when they address the latter as well as the former.
Even if the problem is competency, if developers can't use or work wih the software/library's you're putting out very easily, it's going to be a slow death tied to a few key players eventually moving on. In my experience, the correct path is to address lack of competency with some baseline education.
Does this take more time and patience, yes. But as you did here with your response/reasoning/explanation, it lead to a far more productive outcome and could have lead to an even more productive outcome (an xml parser that supports different entity parsing modes as an option, even if the default has to be DOM2/3, though I don't know why it would be other than backwards compatibility maybe).
It has certainly become more of a conversation about tone. Though in my case, my concern is more about how the tone affects the long-term technical quality by shutting down possible improvements in developer experience, optional behavior, and defaulting to broader expected behavior.
People are going to have different experiences with different ecosystems and environments. Yes, there should be some expectation that they do some work in learning "the Nim way" -- but there's value in trying to learn and understand why they might be coming at it differently if for no other reason that there's often value in adopting the way other things do it.
even if it was originally implemented to be specifically DOM2/3 compliant, it was instead "just made sense." So I guess we're all just coding on vibes here.
Well I remember reading the DOM spec when implementing this code but I don't remember if I did this special case because "it makes sense" or because the spec also suggested this, I wrote this code long ago. And given that you're happy with not following a broken spec anyway (as do I), does it even matter.
It matters in the sense that in order to fix it I need to quite literally loop through all nodes, look for text nodes that are single characters and in the handful of "special cases" just to undo what has been done during the parsing. If the nodes were already entities, this would be a somewhat expensive operation (depending on the size of the dynamic template) that could be avoided.
For more context, this is part of a highly dynamic templating engine wherein templates do not require compilation: https://matthewjsahagian.com/development/
I'll spare the details, but identifying entities as entities for proper handling is important. Then again, I think I've also seen you argue against dynamic/runtime templating engines, so I'm pretty sure I'll have no sympathy for my use case.
So I guess, no, in short, it doesn't matter, eventually I'll probably just fork parsexml and be done with it, and then any time anyone else wants to work with XML this way they need to do the same. We can all be little islands with our own isolated secret code. If that other guy in this thread gets his way, we don't even use package managers... we'll just build everything as a massive mono repo or copy code back and fourth selectively between projects.
I say this with an actual serious amount of respect. Nim is a really great language, and I did not explore it, and ultimately adopt it, lightly. There's a great sense of irony in a language that provides so much power in meta-programming having authors being so oddly allergic to diverse approaches/concerns. I can see the argument that "Nim makes it possible so now it's outside of our concern," but that's not ever going to appeal to a broader audience or build a community. But that's OK too, maybe that's not the goal, and maybe I just chose poorly.
Now obviously for you it doesn't do the right thing, I got that. And a PR that adds a parsing option flag so that you can use the code without your own personal fork would still be appreciated, believe it or not.
It would have been appreciated too with you reopening the issue and explaining for why you need to keep the entities as they are, things do not have to brought up to on the forum for me to take notice.
And even after having spent too much time on Atlas, I do appreciate alternative package managers (see the other thread if you don't believe me), but it would be nice to eventually arrive at one that works for many people which is why I tried to understand your design, without too much luck so far. But that's ok and I prefer not to reply further here in this thread.