Some thoughts about the direction of the project #425
Replies: 2 comments
-
I have a small server that I play on with friends, and I do use ferium to manage the server mods. I'm not sure what the more complex requirements are like; maybe someone can describe them in detail? |
Beta Was this translation helpful? Give feedback.
-
I'm one of those weirdos that loves ferium's CLI for server management. This works reasonably well already, but as @BirdLogics described in #90 (comment) the current design (particularly the config file mechanism) was clearly not originally intended for this usecase. I'd love to see this project improve in this area, and if I had the energy would've loved to help out. Mod management for servers is nowhere near as well-developed as for clients, it'd be amazing if ferium could be the one to fill this niche! |
Beta Was this translation helpful? Give feedback.
-
I'm beginning to realise that the demographic for ferium isn't the demographic I had in mind when I created it. Ferium was made for people like me, who wanted to download mods for their primary Minecraft instance, and that's all. However, it seems plenty of people like the CLI aspect, and are using it for more complex tasks like managing mods for servers.
To be clear, I'm not being dismissive, I'm realising that I should probably keep different things in mind when making decisions in the future. Ferium has potential, but I lack time and direction to realise it.
The first issue is technical debt. I wrote ferium when I was starting to learn Rust (almost 3 years ago now!). I've learned a lot of things about Rust (and programming in general) since, and there are many parts of the program that are old and suboptimally written.
Another major issue is the lack of separation of code. The project has Modrinth, CurseForge, and GitHub specific code peppered all over, and it is ridiculously difficult to add a new 'source' like Actions artefacts, GitLab releases, or generic URLs.
There's also minor issues like the way configs are handled. The current method is suited for users (like me) who mainly focus on just one instance. It also uses JSON, which I picked because of its ubiquity and familiarity with tech-savvies and even non-programmers. However, TOML is likely much better, but I hadn't picked that because of concerns with learning-curve or being scared away from editing the config. Unfortunately, the config file is too complicated, it's still not human-edit friendly. What do you guys think about this.
Beta Was this translation helpful? Give feedback.
All reactions