Im exploring the different ways that can be used to install Magento 2 both locally for extension development and then how this could be deployed into production.
Warning this will be a evolving living gist as I have time to play around.
I found that I could run:
composer create project magento/project-community-edition=dev-master magento2
This creates the folder magento2 and will clone the magento/project-community-edition repository with branch master version can be specified via the = when running this as a single command.
Once this operation has completed. Note there may be instances where you need to install more system packages. I had missing requirements for php-intl and php-mcrypt that had to be resolved before this would complete. You then need to mvoe into the magento 2 directory and run composer install to install all the required magento 2 dependencies.
Is there a need to use the composer-hackathon-module to clone into vendor and then move into the app/code/Magento directory ? Is there any real speed / performance / general reason to do this... First thoughts are that its less "Non owned by me" code to be contained within the repository. Vendor is never part of my repo and is pinned via composer...
My current opinion (subject to frequent change). Use git clone of m2 repo only if you want to submit a patch. The new Connect will have a Composer repo for holding all official releases, all official patches to modules released here (avoid hot fixes) - everyone can get at same time. M2 work on avoiding extension conflicts and improved backwards compatibility should help make it commonplace to do patch upgrades safely.
Next, separate concept of development creating a "build" (like a Java WAR file) from deployment topology as much as possible. So developers on laptop use Connect/Composer to find modules and add them, install patches, etc. Then create a "build" that includes all files to push into production (and test environments). (In Docker, this might be a read-only mounted volume to improve security.) The goal is to keep topology and build separate, so you can test a build in a small configuration with good confidence it will work in production. I am sure there will be some gotchas here - but that is the goal. Use environment variables etc to switch necessary things between dev, test, staging, and produciton environments.
So Composer is always used before the "build" is created, never afterwards. So deploying from dev to prod is never dependent on Composer. Composer is a dev tool only. The "build" will include the 'vendor' directory.
What then do you put into GIT? I have had some say "we want to know exactly what goes into production, so we want to put 100% of build files into GIT and tag it. Others have said "I want to .gitignore the vendor directory". I am not Magento needs to dictate which approach is better - I am happy to explain both options and say "pick whatever you think is better for your project". I can see the advantage in both. Personally I would commit the 'vendor' directory so I can 100% guarantee the set of files I pushed into production. Otherwise if someone deleted an old library version from a Composer repo, or updated an existing released code base (naughty naughty!), then I might not get back the exact code version of a previous release.
So, Composer gets me the first set up, adds extensions or optional parts, gets me patches later, but for normal development and code sharing between team members I prefer to just commit 100% of code to GIT and use that to share - don't make different developers run Composer to get their local project environment up and going.
That is my opinion, today anyway!