There is always a struggle with what should be added to the stdlib and what should not be. I love the work on the Logger and I think it made other logging libraries like Dexter less relevant but pulled in a lot of ideas and made the stdlib more powerful. I pull in lucky dotevn and habitat to most project these days and think something should exist in the stdlib. A configuration pattern is in a lot of libraries and projects probably more common then XML parsing or bigints. Would something like a configuration framework and a std way to load in an environment file be a good fit for the stdlib?
The main reason against this is XML parsing and bigints are well defined concepts while configuration can be done in a multitude of ways. I think it would be quite challenging to come up with something generic enough to be in the stdlib. Having a way to load .env files via the ENV modules might be a better fit as that’s more generally common/well defined.
EDIT: Actually even .env is a bit more complex esp when you get into like .env.local etc. since the stdlib has no concept of what environment its in.
2 Likes
Even though there are many ways to do configuration I think it would be nice to have a way in the stdlib. It is very common for me to include habitat and I think something that comes with the stdlib would reduce the barrier to getting a lib off the ground.
It’s not just that there are different ways, the point is there are lots of different use cases for configuration management. And they demand for different implementations, that can hardly boiled down to a basic generic API (like Log for example).
I don’t think this would be a reasonable feature for stdlib.
Maybe a better approach for your use case of re-using the same shards again and again in different projects would be a customized project template that pulls them in.
1 Like
Maybe there can be a repo in under the crystal-lang namespace in github.