Koodimonni / Composer-Dropin-Installer

Use composer for installing dropin dependencies
Do What The F*ck You Want To Public License
45 stars 12 forks source link

Copy files instead of moving them #4

Open louim opened 9 years ago

louim commented 9 years ago

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 commented 9 years ago

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 commented 7 years ago

Curious if a symlink could be an option too?

onnimonni commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 4 years ago

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)?