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? |
I agree with dmyers about the libraries and helpers. We all would hate to see a library or helper we depend on being dropped, but many of the libraries I have never even touched. And as dmyers said, they were included for reasons not really associated with the aims of CI, but with what the previous owner wanted to do with CI.
In all honesty, I think we should support the good intentions of those behind CI to do what they think is best, and the community can fill any gaps we think there are with our own versions of dropped libraries or other bits of dropped code. Otherwise CI becomes a bit like a 'we do everything and nothing very well' sort of system. I would say that things like calendars, carts and even user authentication run on a framework, and IMHO are not part of a framework. But I suppose it depends where you think the line is drawn between where a framework ends and where an application that runs on a framework begins. As for composer, I do not use it, but I suspect that is because the learning curve is too much for me personally in order to solve a problem that for me does not really exist. I am sure for others composer is a valuable time saving tool, for me, knocking off an hour or two per project is not a real issue given a project is usually hundreds of hours long. But if composer, as a tool, is felt by the CI team to be required for the framework, again I think that is up to them. Let us imagine that CI was to go in a direction I didn't like. That would be a shame, but my personal needs and wants are not the driving force behind CI. That is the people who actually spend their time developing and creating CI. Of course it is nice that we get to even voice an opinion, but in the end I want the CI team to do what they think is best for CI, because it probably will be right for CI, even if it is not actually the best thing for me. Best wishes, Paul.
(04-07-2015, 11:32 PM)Jamper Wrote: 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. (11-27-2015, 09:27 PM)ivantcholakov Wrote:(11-27-2015, 05:19 PM)idealcastle Wrote: I agree with Jamper, no point on making it confusing to install. I particularly don't care for composer since I'm an out of the box person myself. Keep it real clean and simple. If I want to use 3rd party extensions I want to install them myself and the versions, not composer controlled. When libraries force you to use composer, you can no longer directly install the code on your platform without serious modification. Some environments you can not use or install composer, or installing 3rd party libraries within some frameworks, if those libraries require composer installed, then that messes up the whole development. I'm not saying composer is a bad thing, I like full control, I don't need some program telling me which versions of libraries I need, I can do that myself, so for that I just dont need to use composer. I rather download direct code, integrate with my project and move forward, composer is like a "magic" functionality, you can't exactly see whats going on, you just hope it works. I dont like that, I get that new programmers love all the help they can get, so composer works, it does the job, it makes things easier. Just like jQuery, if you use only jQuery and rely on only that for functionality, you start forgetting how to do things within javascript alone.
11-28-2015, 03:35 PM
(This post was last modified: 11-28-2015, 05:13 PM by ivantcholakov. Edit Reason: typos )
@idealcastle
"When libraries force you to use composer, you can no longer directly install the code on your platform without serious modification." - I've got familiar with three kinds of libraries in this regard: 1. There are libraries that offer Composer and manual installation. In case of manual installation they even can be shipped with their own autoloader. Examples: https://github.com/PHPMailer/PHPMailer/tree/v5.2.14 , https://github.com/oyejorge/less.php/tree/v1.7.0.9 2. Libraries that recommend Composer installation only. Probably they might be installed manually, but with much efforts. Example: https://github.com/guzzle/guzzle/tree/6.1.1 In this particular case let us suppose that you badly need asynchronous HTTP requests that this library is capable to provide. Suddenly Composer will become your friend. 3. Libraries that depend on other libraries (or components, or packages, if you like). Then Composer is the only practical way for installation. It would be better if it resolves the dependencies automatically. The third-part author controls this, indeed. Dependencies might be wise or weird. For "weird" I will not give a direct link here for not causing embarrassment, only I would quote my complain "Why composer installs so many dependencies just for using a 129-lines script?". Yes, Composer allows doing stupid thinks as any other tool does. Here you will discriminate not on "Compiser packaging" but on the quality of a given library. ------- "I'm not saying composer is a bad thing, I like full control, I don't need some program telling me which versions of libraries I need, I can do that myself, so for that I just don't need to use composer." If Composer is active on your system it will not stop doing that. And if for a particular case your mind gets shifted, Composer will help. ------- "I rather download direct code, integrate with my project and move forward, composer is like a "magic" functionality, you can't exactly see whats going on, you just hope it works." About the "magic": I suspect that some people make "composer update" on the production server. Well, don't. Do "composer update" on your development environment with versioning control. Check visually what changes are going to be done. Test the system with the new changes. If they are not ok, revert modifications or resolve the problems. If they are ok, commit the modifications (the vendors/ directory, composer.json and composer.lock). Then upload the modification on the production server. Composer is a developer's tool, not a tool for deployment. ------- "I dont like that, I get that new programmers love all the help they can get, so composer works, it does the job, it makes things easier. Just like jQuery, if you use only jQuery and rely on only that for functionality, you start forgetting how to do things within javascript alone." Let us say you work for earning money, otherwise why should you do. Then, everything that saves your time is a priority, in this regard Composer is the top priority. About the jQuery analogy: I can write in the "pure JavaScript" and in the "jQuery" way. But for example, an AJAX call written in a "pure JavaScript" way is not something practical that you need to know. Life is too short for making this. (11-29-2015, 07:06 PM)Hamed Wrote: I don't like composer, It is difficult to use on Windows. Its not hard.. It already has windows installer, after which you can use it really easy with just 1 PHP installation .. Best VPS Hosting : Digital Ocean
I think it is good to have the option, but I will never personally use it. As others mentioned is it good to have the alternative option, for those who want a small direct install, instead of having to install composer, wait for updates and then google the command line to install it.
Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com
I'm pretty sure it was mentioned in the roadmap, but Composer will be an option, much like it is currently in CI3. v4 will have it's own PSR4-compatible autoloader.
I don't recall all of the discussions that led to this decision but it does solve a couple of issues. First is that the framework will still be able to be downloaded, unzipped, and you can go. Second, I have run into issues with Composer on shared servers that had the security settings pretty high so that it was impossible to use Composer as an update script, couldn't dump-autoload, etc, and all had to be handled automatically at that point. However, Composer has some awesome features in the development environment and will definitely be an option. I imagine we'll still be on Packagist and able to install through Composer if that's your desire, also.
Composer obviously has a lot of traction. today. but if you think it will be around forever maybe you should check out PHP Pear.
oh you can't do that today because the php pear website is completely down http://pear.php.net well gee remember sparks for codeigniter? the final package solution for codeigniter? what a coincidence its website is completely down as well. http://getsparks.org i am writing this on november 30 2015 so hopefully both websites come back up soon - but you get the point.
Pear is still going. Their site says they've had a fatal hard drive failure. Which means they've been around for 11 years, I believe. It's true that nothing lasts forever, but to completely ignore a tool that is used as much as this because it will be gone someday? And, truthfully, once you install it on a site it doesn't matter if they go away since Composer will still work on your site.
(11-30-2015, 06:41 PM)cartalot Wrote: Composer obviously has a lot of traction. today. but if you think it will be around forever maybe you should check out PHP Pear. Aside from pear.php.net just experiencing technical issues right now, all of this is not coincidental. Contrary to your opinion, it's a reason in favor of Composer. Composer is a replacement of both PEAR and Sparks, and it didn't become that after they died. They died because Composer did things better and killed them. In fact, Sparks was an isolated, CI-specific attempt at building what Composer is today. I too don't like some things about Composer, but you're just looking for reasons to dismiss it. |