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

Copy files instead of moving them #4

Open
louim opened this issue Feb 19, 2015 · 8 comments
Open

Copy files instead of moving them #4

louim opened this issue Feb 19, 2015 · 8 comments

Comments

@louim
Copy link

louim commented Feb 19, 2015

it would be nice to copy files instead of moving them, so they stay in the package and could be copied over again.

I recently came over a use case: I used the dropin to install languages in wordpress, but decided to cleanup my language dir after the installation since there where files left from old languages versions.

From there, since there are no way to "reinstall" the files, I had to remove the language package from my composer.json, run a composer update, add it back and rerun composer update to get my files languages files back.

@onnimonni
Copy link
Member

Hello louim!

I understand your needs but personally don't think that's necessary because then we would have multiple copies of the same files (pointless redundancy) and I think this should be the default mode.

If you still want to have this functionality you can make a pull request into this repo. Add code which looks optional settings from composer.json -> config section:

config: {
  "dropin-installer": "copy"
}

And then you could rename Dropin::rmove function to something else eg. Dropin::install and add value checking into that which could decide between moving or copying. If you are willing to tackle this please add info about this functionality into readme.md as well.

@ocean90
Copy link
Contributor

ocean90 commented Dec 16, 2016

Curious if a symlink could be an option too?

@onnimonni
Copy link
Member

I'm a bit afraid that those won't work correctly in certain systems. For example you can disable symlinks in apache/nginx.

I'm not against symlinks, but they need to be tested carefully in different branch.

@psrpinto
Copy link

psrpinto commented Dec 29, 2016

Symfony uses symlinks and falls back to copying if the system doesn't support them. I believe this approach makes the most sense. I also agree that files should not be moved from the vendor/ directory.

I realize this isn't exactly the same use case, but the assets:install command is called when running composer so it is kinda similar.

@rask
Copy link
Contributor

rask commented Sep 25, 2017

Does this still move instead of copy or symlink? Having a drop-in file within the local project repo (as a Composer path package) which is not ignored in Git would pose a problem if the developer needs to reset the installed drop-in file after each composer install.

@onnimonni
Copy link
Member

I haven't done any changes to the behaviour so It still just moves the files.

This wasn't certainly designed for local repositories.

I'm happy to accept a PR for your use case.

@rask
Copy link
Contributor

rask commented Sep 25, 2017

To clarify, I guess the issue is mostly with path repos that are symlinked into place when running composer install. If the package is copied to vendor or similar I guess it might work as is. I made a PR in any case.

@szepeviktor
Copy link
Collaborator

I'm not against symlinks, but they need to be tested carefully in different branch.

Does Composer symlink vendor/bin/* files on certain systems (Windows)?

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

6 participants