@mindplay: I don’t want to argue with you and my post wasn’t about your experience, just about dependency management and if it’s simple or not. Eg. Yii 1.1.13 broke some of my extensions (until I fixed 'em) just because a tiny change was introduced with table aliases.
@mike: Let’s turn this around … the problem is that we’re currently using extensions, which were never developed with composer. Also there are no guidelines how to structure an extension and how to create some running examples for your extensions, maybe just because we never had a tool like composer! btw: I opened issues for not bundling Yii and the docs in the newer versions and Tony and Chris already approved it.
But the Bootstrap stuff is still the perfect example why we need dependency management and not just downloading a tar.gz and place it somewhere, eg. yii-bootstrap-editable depends on yii-bootstrap and the editable plugin, which depends on Twitter Bootstrap and jQuery, even with cross-dependencies inside and to recompile the LESS stuff for customization you’ll need a (lessc) compiler which is actually able to parse all the stuff, 1.3.x in this case, not 1.4.x - which may be used by Bootstrap 3 then…
I am very late at this party but i have a simple question since i started using composer for a while now and it makes things easier for me at least.
Right now, i use Yii as a package for composer which is nice because yii will go into the “vendor” folder in the root of my project. This also allows me to use other libraries that are not meant to be used with Yii, for instance, i use Symphony HttpFoundation component because Yii doesn’t have a response class, but i need one.
The question is, with Yii’s method of integrating composer, will we be still able to use other packages that are not meant for Yii?
Just another note, do not make us stick to a folder structure, this is a deal breaker for me and i am sure it is for others. I want to arrange the folders as i want(like i am doing now with Yii 1.1.x), not to be forced to do it because the framework dictates that for me.
What would be the use of composer then? It would just be a third party Yii installer. No, I’ll eat my shorts if that’s the case and post the pictures in here. Promise!
I am more than 100% sure that Yii 2.0 won’t force any app structure on you. That would be a absolute deal breaker for 80% of the Yii developers. But if you mean that you want to put composer’s vendor directory somewhere else than you can use the vendor-dir option in your composer.json file.
@Haensel - I was just asking, maybe they want to use it only for the framework extensions/modules, i dunno, i wanted to be sure(but keep those shorts handy, you might get the chance [:kidding:] )
For the second point you got it, it’s okay if we can still use what directory structure we want.
You can handle an installation with it, but you’re not forced to do so, even with Yii2 - I strongly assume. But the way the Yii2 repo will be structured is important, see also @Mike’s comments.
What I really, really like about Symfony2 is when you run the composer script to create a new project…
It’s just awesome!
I hope that Yii will utilize those possibilities for it’s web app generator.
With regards to extensions… I’d prefer to have more control (which I’m sure I’m gonna get) because most of the time I find myself modifying extensions to suit my needs.
Only a handful of the extensions are actually installable as-is, i.e. good enough.
But I guess you can point composer to alternate repository paths - haven’t really looked too much into it.
Isn’t that a great example of something Composer can’t help you with?
I’m not trying to argue with you either - all I’m saying is, Composer solves a set of problem that aren’t really a problem for most developers, most of the time. Therefore, it has to be simpler than managing said problems on your own. All I’ve seen so far, is that things that were trivial (or at worst somewhat problematic) before, are now damned near impossible, incomprehensible, and a damned nuisance when it doesn’t work as prescribed.
I thought that C++ programmers were the worst of the lot.
That was until I met you guys.
Having said that, I want to mention (again) that what I really liked about the Symfony2 installer script was that it did all sorts of things behind my back (or, rather: right in front of me, just hidden) like copying files, downloading packages, setting everything up, running tests, etc.
That looked rather neat.
Imagine having such neat generator scripts for Yii.
But, as Mindplay says: we don’t want to complicate the heck out it.
It is is a great example because the only thing I had to do was setting a version constraint to 1.1.12 and not reminding every co-developer of the fact, that he shouldn’t use 1.1.13 for new and also for existing projects, eg. if there was an updated scheduled.
And even better, if someone would have installed an extension, which for example relies on a fix in 1.1.13, composer would have told you - in advance - that there are problems with these settings, I think that’s awesome.
We should create a poll </ironic>
That depends on the workflow I guess. I’ve created our project templates with git in the beginning and then with git submodules to modularize them - hell, that’s a mess, with far less control.
What’s so intransparent and complicated with composer? It just runs git clone, git checkout 1.0.0.
Btw, I just remember this posting on composer-dev from you.
Could you give me an example of thing that’s “now damned near impossible, incomprehensible, and a damned nuisance when it doesn’t work as prescribed”?
If i understood composer right then if you run composer update (OT: which i can, because i found it quite unusual to call a executable composer.phar, so i created a symlink) it will update all installed packages to the latest version.
I can’t remember that I ever needed to do this in any serious project. You hardly have to update everything! Because you have a running system that is very sensible to changes. If you really need an upgrade of a package, it will be because there’s a new feature that you might need. So you upgrade that single package only. In that case you will have to check all dependencies manually anyway, because you want to make sure, that none of the changes will break your existing app.
I never had the urge to automate this - it’s much safer to do that manually. [size=“2”]You may say “But you can configure exactly which version you want for a package”. Well, that’s exactly what you can do with git submodules, too. And it’s less hassle for your co-developers as they have one tool less to care about.[/size]
Never change a running system - you don’t have to update your project.
It’s up to you if you want to update the whole thing or just a part of it.
My co-developers shouldn’t run composer update anyway, they have run composer install which gives them all the same set of packages.
What if Yii 1.1.whatever introduces an important security fix, but the update would break your app?
Git does not know anything about dependencies, also for updating to the next stable (tagged) release you’ll have to manually look up the tag or commit.
Then pull the submodule, go up, commit and push the submodule in the main project, test your app and repeat these steps for the all the dependencies which you also have to look up manually … Until you realize one step before the finish line, that you’ve run into an incompatibility and have to revert everything and find another solution.
btw: Do you also don’t update your OS with apt-get upgrade?
How would composer help me here? If i let composer do it, and then find out that parts of my app don’t work as they did before it requires another step to fix it: I need to figure out what composer actually did during the upgrade. If i do everything manually i always know what i did.
An OS upgrade is a different case: Here i can assume that many developers have thoroughly tested the upgrade path. In my application that’s usually my job. Yii’s user base is just not big enough to make sure that each and every package was tested in all possible combinations with other packages.
But anyway: I don’t think we need to discuss the pros and cons of composer much longer. As long as it’s optional in Yii2 everyone should be happy in the end
