config
config copied to clipboard
hassankhan
Change the namespace?
I don't know, Noodlehaus seems to be a really lousy namespace for this, and makes it a bit hard to take the package seriously.
I have a suggestion ... maybe we could move the package to The PHP League, I'm sure we check all the boxes.
For me it is indifferent, but we have to create an auto redirect from this repo. Anyway I think that this could remain here.
Pros:
- More exposure: both in terms of users and contributors
Cons:
- Namespace change (already done here)
- Repo move
That's a great idea!
With regards to the redirect, once we transfer the source tree under the league, the redirect will automatically happen (covered by github).
As for the check list, wrt the Changelog, will the commit history stand for this?
Can I just create a branch called league and we do all the pulls against that one for this effort?
I've already done the necessary work, I think, just a case of applying to the League. Would you like to send the email to their mailing list or should I?
With respect to the changelog, I think we don't need to have one ready right now (though we could). I think the commit history isn't quite specific enough, all we really need to do is pull significant commit messages really.
Instead of maintaining a separate branch, I was thinking we could bump to version 1.0, if anyone wants to use the pre-League version they could point to an older tag.
Draft email: Package Proposal: Config
Hi all,
We're collaborators on a simple Config package, and we think our package would fit in quite well with The League.
https://github.com/noodlehaus/config/
What It Does
Config is a file configuration loader that supports PHP, INI, XML, JSON, and YAML files. Files are parsed and loaded depending on the file extension.
What Makes It Different It is by design a really simple package, it simply reads the files and provides them to you through an object interface. Config cannot write values back to the file (also by design). Config has also been around for quite a while, and is fairly mature. It uses exceptions, namespaces etc., and we've made a separate branch that we think holds up to League standards.
Where It's At It's currently at 0.2, we could bring it to 0.9/1.0 before it came into the League. We have 100% test coverage and a fairly detailed README.md file, so we think we tick all the boxes.
The Future
We could maybe try and code to interfaces, also try checking MIME type of file rather than extensions. Also, we could use more documentation on use cases, one simple one is extending the Config class to set your own default options.
Thanks for your time, and we hope you'll like our package!
Davide Pastore Jesus Domingo Hassan Khan
Awesome, great. you can go ahead and apply for the package, Hassan. Then if anything needs to be done, let's file the tasks as tickets so we can pick and clear them one by one.
Added collaborator status to @DavidePastore.
should be no issue dropping 5.3. we could either drop 5.3 entirely, or supportit unofficially.
Yeah we can just tag a release as the last supported version for PHP 5.3, no probs.
Really excited to see if this makes it into the PHPLeague - its a package that is so useful and essential in any app I feel.
Thanks for the kind words!
Just wanted to post this here: https://github.com/thephpleague/thephpleague.github.io/wiki/Package-Submission
Pinging everyone: been a few replies to the email thread, not thought of a response yet but input is very welcome. Thanks!
What ready? In here is fine I guess. Keep communication open ;-) On 25 Feb 2015 23:05, "Hassan Khan" [email protected] wrote:
Got something ready, shall I post it here or somewhere in private?
— Reply to this email directly or view it on GitHub https://github.com/noodlehaus/config/issues/20#issuecomment-76070670.
Okay, here it is:
Hi all,
First of all, thank you all for replying!
Honestly speaking, I hadn't seen Zend's package before (or heard of phpdotenv, cheers Jonathan). The only reason I stumbled into this package is because it showed up before zend/config on Packagist, and was exactly what I needed at the time (and the rest is history).
I had seen the Symfony one though, and I've gone back and looked at both more thoroughly to prepare a better argument.
Config's own merits
Config aims to be as simplistic as possible, we don't think it's ideal creating a few objects just to get going. You can load in any file of any format without needing to worry about setting up a thing.
Also, another use case that I haven't seen (yet) in other packages is being able to easily create a config object with preset values. This can be useful in any implementing library/project, rather than passing around an options array it can be encapsulated and saved (IoC or however).
symfony/config vs Config
I personally think it's a tiny weeny bit over-engineered. It seems I have to instantiate a fair few classes before I can even use it properly. It does let you validate the settings, which Config doesn't, but it could easily be achieved by using a simple validation library (valitron, anyone) in a subclass.
zend/config vs Config
zend/config requires a separate class instantiation for each filetype, or another class which can only read PHP arrays. Otherwise it's pretty much the same - had I known about it earlier I probably would've used it.
phpdotenv vs Config
I think that they solve different use-cases, I would use phpdotenv for things like API keys, etc. (sensitive credentials), and I'd use Config for managing my application's runtime settings (Unless I'm mistaken?). That said, I think they would both work nicely along each other, and possibly even complement one another (I've gotten another idea).
I guess my closing argument on this topic is that while the above packages do solve "the problem", I don't think they solve them particularly well from a user's perspective. I'm a big fan of how League packages tend to be simplistic and integrate awesomely well with pretty much any application I've used them on so far.
About using all available loaders, we're currently thinking about changing this to allow users to specify which loaders they require, so there's that.
I hope that answered your questions and hopefully sold it to you :)
If no-one else has anything to add, I'm going to post the reply above to the mailing list when I get home tonight. Thanks!
Considering there's been no activity in this issue nor on the thread in the php league mailing list, should we assume Config will not be moved to a new namespace?
Yeah they didn't seem too keen on it, but I don't think anyone is averse to changing the namespace if there's any better suggestions?
Sooooo ... I've set up a new GitHub org and I'm planning on moving it there, unless anyone has any objections?
Not really any advantages, per se, just been waiting to do this a long time but didn't have a decent vendor namespace.
I guess one advantage would be everyone in the org is an allowed contributor, so lessens the burden overall maybe?