Poll: Incorporate Composer? You do not have permission to vote in this poll. |
|||
yes | 28 | 46.67% | |
no | 22 | 36.67% | |
maybe | 10 | 16.67% | |
Total | 60 vote(s) | 100% |
* You voted for this item. | [Show Results] |
[split] Composer? |
Question:
With CI 3.0's inclusion of Composer, would adding composer packages to the native build be out of the question? I understand wanting to keep ci on it's own and I understand how easy it is to implement something like Whoops error handling. Just general curiosity. PS: might want to add that adding Auth is out of the question . Don't want a flame war like we've had in the past.
"adding composer packages to the native build" ??
If by that you mean building a bunch of goodies with a release, incorporated through composer - no. That leads to the same problem mentioned - trying to choose which of a number of third party packages is best, or <shudder> including them all <yikes!!> If by that you mean adding any such packages to *your* CI install, that is an intended use of a tool like composer If the core framework has a dependency on a third party package, for instance vfsstream for the travis-ci, then that composer dependency would properly be included in what I think you mean by the "native build". Wait a minute - that one is already
James Parry
Project Lead
By default I think that there shouldn't be any 3rd party required libs. For all things routing, db and etc, there should be CI natives and perhaps extensions which can use 3rd parties.
Perhaps we can plan (yet its too early for that) to have composer based start-up projects (with just running command) Create project with composer. With that command we can defined 2-3 types of applications as Simple app (as it is now) , Resource app(RESTful based optimised app), Advanced app(with a lot of things setup-ed inside it). For such thing its to early even to talk so this is just an future idea. Best VPS Hosting : Digital Ocean
Translations should also be able to install through composer. Or merge them with main project and distribute it with all official translations.
Yes for Composer, but make it optional. Composer could be recommended, but there should be easy way to do it old way and the old way should be well documented.
For example, on my actual Linux Mint 17.1 installation with XAMPP 5.6.3, the Composer do not want to work with SSL (problem with OpenSSL), so I am practically not able to using it. I wanted to try CakePHP and Laravel. CakePHP have in documentation mentioned GitHub, but Laravel suggests only Composer. So the beginner with broken Composer (or OpenSSL) is not able even to install and try Laravel. From my point of view, CodeIgniter 4 should be modern and using Composer. But CodeIgniter 4 should be also beginners friendly like it always was and support easy and well documented old way installation and settings.
Yes, CI has reputation as beginner friendly framework and suggested way to install it should remain as it is now (just unzipping). Suggesting CLI commands to newbies is BAD idea. For sure there should also be official way to install it with composer for more advanced users, though.
(04-07-2015, 01:18 AM)Muzikant Wrote: Yes for Composer, but make it optional. Composer could be recommended, but there should be easy way to do it old way and the old way should be well documented. For myself, I much prefer the "old" way, over using Composer. I have no objection to making Composer an option, but I would strongly object if it become a requirement for installation.
CI 3.1 Kubuntu 19.04 Apache 5.x Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing. Clarity is desirable over Brevity every time.
I agree completely, One of the popular selling points of CI is it's ability to be downloaded and setup with ease, perfect for any developer. I fear that if you start to add more dependencies such as Composer and "hoops" to jump through it will become a hard task for someone learning PHP/MVC to get going.
CI's installation method is perfect as is. "If it ain't broke, don't fix it". What I would like to see is a modern approach to file uploading/uploading management specifically an Ajax drag n drop process.
I think the core should be 100% included (which BTW I currently download via composer). As for some of the other Libraries and Helpers. I think the team should deprecate the ones that just add "busy work" to the project and the team (calendar, cart, ftp, javascript, etc...). Anyone that needs them can download a zip file with the "last supported versions" and drop them in as needed. Having the team continue to support a FTP or calendar library seems like wasted of their limited time.
I think the "core" should be as slim and fast as possible. The team should focus on moving "core" components forward not worried about supporting a calendar library. I didn't pick CodeIgniter because it has a smiley_helper and Calendar library. If a user says they are going to drop CodeIgniter because those aren't "core" features anymore. They aren't going to find another framework that has those built in either. A lot of those where part of Ellis Labs Expression Engine. It's time to move on to what really matters. Core Speed and Simplicity. Just my 2 Cents. DMyers |