What the description says; move the generated autoload.php file (and any other PHP runtime dependencies it uses, if they aren't already included in the file) from the hidden folder vendor/.composer into the vendor folder.
This will make it easier for the user to include the file and also see what it contains, as it is not hidden. It will also reduce confusion as well as reduce the risk of forgetting the file when copying or uploading the project for testing.
For backwards-compatibility I suggest Composer could create a vendor/.composer/autoload.php file containing something along these lines:
return include __DIR__.'/../autoload.php';
Maybe it should also raise some kind of notice, but that might be a bad idea as it introduces more noise when using the autoloader.
I agree that we should have vendor/autoload.php, that would be way more user friendly. But imo we should keep the .composer stuff and simply add this as a proxy, that would look like this:
return require __DIR__.'/.composer/autoload.php';
If the user wants to use autoload_namespaces.php, he can still go get it from vendor/.composer.
What was the reason for putting the autoloader contents inside of a hidden folder? I don't see why anyone would want to try to hide away a core bootstrap item. Placing it inside of the vendor/ would be more sensible.
An alternative approach would be to allow a custom autoloader folder in composer.json
@CraigMason the reason was getting out of the way. It used to be in the project root, then got moved to vendor where it indeed makes less sense to have it in a subfolder. That said I like the idea to just add a proxy in vendor/autoload.php, so that we keep everything together in that .composer dir, because in the end, it's just an implementation detail and you should not have to go muck around in there.
It may be an implementation detail, but it's still an important set of files to be considered during the general application bootstrap process. With larger applications, the bootstrap process is complex and the autoloading is a very important part of that.
Having the autoloader items inside of a hidden folder has a few disadvantages:
I like the proxy script, but I think having the option (in addition to the proxy?) to configure the autoload directory in composer.json would provide the option for more specific needs. As far as I can see, this wont interfere with any other parts of the autoload system.
I'm not too keen on adding options just for the sake of it, because they break conventions and expectations. You do have a point about dot files being ignored though. I'm just not sure if it should all sit in vendor/* or if we use another subfolder name.
Having everything contained in a subfolder autoload/ (perhaps) would work well. Would there be any reason to not include the files in subfolder?
installed.json really has nothing to do with autoloading, and using composer or other names as dir name can be confusing because if you have composer/composer as a dependency you'll end up with vendor/composer/. Not a huge deal, but not so nice. Ideally we would find a good name, and then just mark that as a reserved vendor prefix.
So just dumping it all in vendor/* sounds easier. It's just 5 files anyway (for now at least).
I suppose the difference is installed.json is metadata specific to composer, whereas the autoload contents is effectively disconnected from composer once it is (re)generated. Autoloader files need to be deployed, installed.json doesn't.
Placing autoload files in vendor/* does sound easier if you forsee namespace clashes with packages (unless you reserve it, as you mentioned)
Move .composer files out into the vendor dir, fixes #497
@Seldaek - since the major BC break has now occurred (where the autoload.php is located), maybe you could consider adding a non-hidden subdirectory for the 4 autoload.php dependencies?
I'm considering for sure (cc @fabpot) but I don't want to do crazy back & forth, so I would like arguments from both sides and a clear plan before doing anything.
@drak any non-hidden directory is likely to conflict with a folder created to install a package
@stof - "is likely" is probably a bit too strong, but one could just make "composer-autoloader" a protected key in the "require" schema. I'm only suggesting a non-hidden folder because this ticket is about the disadvantages of hidden folders? Unless it was only about the fact that the autoload.php was hidden - if that is the case, keep the .composer folder for the autoloader deps.
@drak Why not simply keeping them the way they are now, i.e. directly in vendor?
problem still stands that installed.json/installed_dev.json don't really belong in a folder called autoload. I liked my good ol' .composer. Maybe _composer is the best compromise (for all except autoload.php), unless underscored-dirs are indeed ignored by some build tools as well. Anyone knows?
@jalliot - see https://groups.google.com/forum/?fromgroups#!topic/composer-dev/fWIs3KocwoA
How about -composer, ~composer, composer_ or composer_deps and make it a protected key that cant be specified in composer.json
But why is a hidden dir for the dependencies of composer objectionable (i.e all except the autoload.php)?
@drak making it a protected key is not easy as the key comes from the name chosen by the package owner. If someone creates a tag without validating the composer.json file previously, the tag will be broken and cannot be fixed (git tags are meant to be immutable)
Please see https://groups.google.com/d/msg/composer-dev/fWIs3KocwoA/R8oujVRF5nkJ for a conclusion, and voice your concerns if any.
I find the one month compatibility period advertised in https://groups.google.com/forum/#!msg/composer-dev/fWIs3KocwoA/nU3aLko9LhQJ to be rather worrying. Given that projects like phpbb are now using composer I would suggest that a more appropriate compatibility period would be, say, one year, especially taking into consideration the fact that it probably takes all of one line of code on composer's part to support said compatibility.
@p I find it already quite generous that we offer early warnings, then today switched to an E_DEPRECATED, and now will wait one more month before removing it for good. Composer is alpha software, and while I'm thrilled that so many people have started using it, I don't think it's right to let that slow us down right now. That said I've been pushing hard the last few months to do all the BC breaks ASAP, given the amount of users. I have added BC where possible, and tried to warn people through ML/twitter/IRC. Hopefully we will soon hit the first beta release and then things will settle down.
As naderman explained to me we only use composer for development, which means this change will "only" require keeping two versions of composer around when checking out various editions of develop branch.
This almost works as you provide releases on the download page (http://getcomposer.org/download/), but these releases are not labeled with dates which makes it tricky to determine which release I should get for code written on a particular date. I filed composer/getcomposer.org#18 to add the dates.
Update test bootstrap include for composer autoload.php