Open nickl- opened 12 years ago
composer will pose a challenge since it doesn't do global install and doesn't behave like a package manager should.
./vendor
The main issue/concern really is that it shouldn't become part of the general search/install/info all as it will causes hassles. Not sure how we normalize this ambiguity with install and not confuse everyone.
If there is ever a PM that is too off the beaten track to be included this is it.
There's a way to "install" composer globally.
You're right about composer not being a package manager. It, definitely, is not.
Particularly, I think that composer shouldn't be handled by aero.
We could make it local. User cd
to the project folder and the composer adapter will be fired only if the composer.json is present in the current dir. Could be similar for npm.
@oliveiraev by globally I was referring to "install packages globally" in the sense of how pyrus or npm would handle those. composer anywhere on the path is "global" but at this point we are not concerned about installing the pms just making them all behave the same install, info, search etc
@alganet what do you look for with npm? The presence of a node_modules folder? This could be the trigger for pyrus too (the vendor folder)
What bugs me is that $ aero install composer:phpunit
must call $ composer require phpunit
which may be confusing for the end user. Or maybe not? Bottom line is: aero install
≠ composer install
thoughts?
So how do we include composer in the global search and then throw exception if you try and install without a package descriptor? ...or leave it to composer to bitch about it as it probably will?
This approach raised me some thoughts. How about an aerofile ??
With make, we have a Makefile. A Gemfile brings all the gems that bundle install
should grab. The same applies for composer.json, component.json, package.json and on and on and on.
Supposing that we have a Frankenstein project. Wordpress (brew/apt/yum/emerge install mysql/php) with some pear/composer packages and uses Compass(gem install) to minify CSS and uglifyJs(npm install) to concat and minify the javascripts. Also, the Google Closure Linter (easy_install) performs the syntax check for javascripts.
A simple aero install
or just aero
can read the aerofile or else scan for the respective depFiles on the project root (assumes current folder) and do the whole magic.
Felt deeply tempted to contribute with composer project and add a --global
parameter. Will check for the existence/availability.
Keep up the good work!
You can already do "aerofile" =)
Configuration argument:
It is possible to load aero configuration from an input file.
@filename Append "key, value" (where applicable) to a file one
argument, value pair per line. To tell aero which
file to use for configuration specify the path and
file name prefixed with an "@".
It should work for more than just configuration already... but I love the idea of Makefile-ish Aerofile =) recipes to deal with complex configuration management and possibly deployment automation. Wicked! Tx for sharing.
I am a little concerned about making packages install local, they usually come with stacks of support libraries and stuff too which makes sense for them to be global. If you can modify it wont you then be breaking the integrity as these packages will still be considered as installed but may not be on the path nor should they be considered permanent. I have a feeling this is a can of worms you got here... =)
@oliveiraev why don't you look at writing an adapter for bower (See #24) first while you familiarise yourself with the architecture? If you see you have a moment... that would be awesome!
How about install composer globals on the first hit of include_path
No current implementation
This task needs to be completed as part of milestone Version 0.1 see #2