Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wish: Installing packages as submodules #270

Closed
leolara opened this issue Jan 30, 2012 · 7 comments
Closed

Wish: Installing packages as submodules #270

leolara opened this issue Jan 30, 2012 · 7 comments

Comments

@leolara
Copy link

leolara commented Jan 30, 2012

I have a project that I manage with git and would like to manage its dependencies with composer. On the other hand I am using Cloudcontrol PaaS and they require me to have all dependencies as git submodules or include them in the directly in my git tree (last option is not an option).

For what I see composer install git dependencies with clone instead of with submodule. Why is this the way to go for composer?

Would you accept a patch that as an option install dependencies as git submodule or is this something previously discarded?

@Seldaek
Copy link
Member

Seldaek commented Jan 30, 2012

Typically I think those providers should learn about Composer and use it to download dependencies. I can't blame them for not doing it yet though, because it's not stable enough. I know of some other cloud provider that is investigating it though, so there is hope.

I'd like to avoid submodules because typically the vendors should not be cloned from git, and they should also not be checked in your VCS.

@leolara
Copy link
Author

leolara commented Jan 30, 2012

I think composer is the way to go to manage dependencies in PHP and I am really surprise that nothing like that was done before, only the PEAR system. However, I do not think it is so mainstream now that all cloud providers will implement it, hopefully will happen eventually.

I see the point that dependencies should no be managed by the VCS, but by composer after the project is checked out from the repository.

However, installing dependencies with git clone is already implemented, and for my use case currently at Cloudcontrol to do the same but with git submodule would solve my problem. Also, I think to use git submodule is a less bad solution than using git clone.

@Seldaek
Copy link
Member

Seldaek commented Jan 30, 2012

The thing is, git clone is only done when there is no zip available, or when you use --dev to specify that you want to work on the vendor libs. Later on this should be possible per-dependency so imagine you need to patch symfony you could do composer dev-install symfony/symfony or something like that and it would reinstall the package via git instead of zip. git clones are slow since they pull the entire history along, which is really not practical since it slows down deployments, and it will only get worse with time.

So no, I don't think git submodules are a better alternative. This "install via git" thing should be for development purposes only. I understand your problem but I'm not sure if it justifies that we do a temporary fix it with something suboptimal, because removing features is always difficult later on. As you say it's not mainstream enough, and not stable enough, so if you don't mind please be patient and keep maintaining submodules by hand for now. Of course the other option is to patch Composer and then just use your fork for the time being. Send a word our way if you do so, depending on how the patch look maybe we can merge it after all.

And whatever you do, I think sending a mail asking for composer support to cloudControl would be good, just so that they notice it exists and there is some demand. I will be happy to help them if they want to implement it and require assistance.

@leolara
Copy link
Author

leolara commented Jan 30, 2012

Thank you for your time.

I will send an e-mail to CloudControl talking about this, but I am not very hopeful as their architecture has the only way to deploy by git and then that filesystem is read-only, so I cannot run composer once deployed. They would need to change their architecture or perhaps I will have to install the packages to the temporary folder.

I guess the simplest for me know is to keep the dependencies by hand with git submodule. I just was enthusiastic on using composer on a real project.

Thank you for your hard work. These things are transforming PHP into an enterprise platform.

@leolara leolara closed this as completed Jan 30, 2012
@Seldaek
Copy link
Member

Seldaek commented Jan 31, 2012

If you have a temp dir you can rely upon, using composer to install in there should be doable. You can specify the vendor dir in "config": { "vendor-dir": "/tmp/.." } and it will install there.

@leolara
Copy link
Author

leolara commented Jan 31, 2012

Well, I thought about that but the temporary dir path is in an environment variable, so I think I would need to do another trick on top of that like to generate also composer.json on the fly.

@Seldaek
Copy link
Member

Seldaek commented Jan 31, 2012

You can use this command to run it:

COMPOSER_VENDOR_DIR=$TEMP_DIR php composer.phar install

Should work, granted you adjust $TEMP_DIR obviously.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants