Atomic core and packages

Thinking at where the packages would be downloaded/stored - would this be next to the framework, like official Widgets and AR classes are now or in the "extensions" folder of each Yii application? I think the answer is open to debate. While packages like AR, database drivers and widgets could sit nicely next to the framework files, packages with modules would better be in the "extensions" folder of the application.

I raised this question also, because at the moment we're having different directories for modules and extensions ... and there're also themes which could be distributed with the package manager.

I think composer uses just one (1) directory to store the files. In its case it's 'vendor', but this can be customized, so for Yii this would be 'extensions'.

At the moment we could put all modules under extensions, we'd simply have to configure the modules with a class property. I think this would be also possible for themes, if you change the basePath property - the only thing which would not work then is using the baseUrl property, because it would be inside the protected/extensions folder.

I am working on this feature for Phundament 3, but it's not ready yet. If you want to you can have a look at these two composer.json files to get an impression:
1. phundament (skeleton) --> download p3media
2. p3media --> download p3extensions

Hi,
I'd vote for Composer/Packagist.
In docs they said that can be added a custom installer based on type key, which let us build a set of package types based on Yii architecture: yii-module, yii-component, yii-extension, yii-theme, etc.
Best.

I know I recommended Composer early on, but now that I have actually used it, I have to say: I strongly recommend that using Composer be optional - a lot of Yii users will not be able to figure out how to even get it running properly.

It has so many dependencies on so many binaries, system paths, etc. - and there is currently no "one-click" installer available for Joe User, who for the most part also will not have an easy time understanding the concepts, how to correctly create package metadata, how to deploy packages correctly to Packagist, how to set up post-commit hooks, etc. etc.

The bottom line is that there is a hefty learning-curve.

I'm not personally a fan of having this amount of complexity and dependencies, just so you can type "install" at a prompt and have it download and unpack things for you - unless we're talking dozens of packages, I can do that myself in minutes. I just don't see the value.

That said, the community at large is embracing Composer - to the point that you're considered a wash-out and a loser if you don't support it, so I support it, reluctantly, since I can't propose a better alternative...

I finally managed to actually install and run Composer - they provide a one-click installer now that takes care of setting it up correctly. It did not work with my PHP 5.3 installation, but a second attempt with my 5.4 installation got it running.

I spent about an hour and a half trying to set up a project with one dependency, read through some blog-posts and portions of the documentation, and finally gave up. This is not the first time I've tried either. The amount of documentation is entirely overwhelming, and not much help at all.

For comparison, I installed NPM (the Node Package Manager) and had it working in 5 minutes - not knowing the first thing about Node.

Composer makes me feel like a complete idiot. Who was it that wrote recently, that good software should make you feel smarter, not dumber? Composer takes essentially simple tasks and supposedly makes them simpler. Until it actually makes things simpler, not harder, I won't personally be using it. I have limited time and real work I'd like to do.

Even though schmunk really tries hard to convince me of composer in our projects i tend to agree to mindplay. It makes easy things unneccessarily complex and obfuscates what really happens in the backround. I prefer manual control. With composer you have to trust the package author that he got dependencies and all these things right. schmunk, remember the problem, when the yii-bootstrap package for some reason pulled in another copy of the full Yii framework? Yes, you may be able to fix that if you read enough about composer. But i don't want to spend time on this. I can't see, why this is easier than downloading and extracting a simple .tgz file.

So my conclusion: Composer invites you to bloat your project with 1000 extra packages. Either because you configured them as you "may need them" or they where pulled in in the background as some dependency without your notice.

Come on, it all depends on how extensions are bundled. As long as each extension is self-contained, you're right. Then it's only a matter of downloading the one single .tgz and extracting it. But as soon as extensions start to reuse existing other libs, which in turn might depend on other libs again, dependency management helps a lot.

And personally, I think it's not only about the downloading and upgrading. I think as soon as people start to use a dependency management system and get used to it, it really encourages them to reuse existing packages instead of rolling their own (partial) solution for every supporting task. Having more tools at hand, they can focus more on the actual problem they're trying to solve. And this should lead to slimmer, more focused and again more reusable extensions. I think it can be well compared to the unix philosophy: "Write programs that do one thing and do it well".

That being said - I also struggled with composer, even when trying to use it for the most simple tasks. Guess I need to put some time in it, get used to it, learn more about it. Just as with every new tool (thinking about git...)