Publish to packagist
mishak87 opened this issue · comments
Hi!
Your package has composer.json but is not available on packagist.com please set it up!
I know! However it has occurred so historically that there are three parallel branches (one "raw" and two customized for the certain PHP frameworks) so it cannot be tagged with the proper version numbers and that is the reason it's not on Packagist. To fix that it would require to split this repo into three.
Personally, whenever I need to include this package into a project, I add a repository key to the main composer.json and require the package with a specific commit hash. It's far from ideal, but it does the job.
Also, if you happen to use a private Composer repo, such as https://github.com/composer/satis, for your work, you may add this package to it and not bother with adding another repository to your projects.
Framework integration could be solved with adapter packages. Keeping core functionality in l18n an adapters in l18n-nette and so on.
Library looks quite stable so extracting adapters from branches should be straightforward.
This while problem has been actually bugging me for quite a long time and here's what I figured:
The adapter in a similar style as Nette components' bridges will work well enough for Nette, although then there is a question whether the composer.json is to require any Nette component involved (it should since it uses some), but what about those who don't care about the Nette adapters? They sure wouldn't like ending up with some extra libraries sucked up into their projects that they won't ever use.
And with the Kohana branch, it's more difficult, because that version is built as a Kohana native module (it was actually developed as one first and then branched off to 'core' and Nette versions) and as such is a subject to some limitations, such as following a certain directory structure convention to use the Kohana autoloader (PSR-0 compatible). Composer wasn't even around back then! A proper separation would require the 'core' i18n package to be a "subpackage" of the native module, so to speak, but then it will have to supply it own autoloader for the subpackage. A separate native module requires a separate repo, or at least a tricky git-submoduling... Kohana doesn't seem to be very much alive these days though, but I still wouldn't like to drop a support for it.
What do you think about the composer requirements of the Nette components? Or possibly other optional requirements. I think I'd be willing to give this a try if there's a good solution.
Hi sorry for such late reply.
I would suggest extracting Nette related classes to own package (and repository) that would depend on this one.
I know and I knew that would require some ground-level edits that I didn't have time at the moment. Time that I have found now. Whew!
https://packagist.org/packages/czukowski/i18n-nette
https://packagist.org/packages/czukowski/i18n
At this point all tests pass and the code coverage hasn't decreased. Though I can't rule out any migration-related issues, so use with caution.