Add option to preserve symlinks

dphoyes commented 9 years ago

Previous behaviour was to resolve each symlink locally, and reupload the referenced files. However, this fails if a symlink points to a directory. For me, the desired behaviour is to make no attempt to resolve symlinks, and preserve them in their original form by creating identical symlinks on the remote computer.

This behaviour can now be enabled by setting preserve_symlinks to true in the config file. By default, the behaviour should be unchanged though. Currently only the SFTP adapter is supported by this parameter, though it should be possible to make it work for others too.

Apologies for the large changeset; please let me know if anything should be implemented differently.

scttnlsn commented 9 years ago

I think what you've described is definitely a better way to handle symlinks. In addition to the directory problem you mentioned, the current solution is also suboptimal since it does not track changes to externally linked files. With the current solution I see no clear advantage over manually uploading symlinked files and I'm inclined to remove the existing functionality completely.

I think your solution could also be made to work with the FTP adapter but not for S3 (and perhaps some future adapters). What should happen in that case? Do you think the adapter should implement a no-op symlink method? Or should we try and upload the linked file?

Since there are various different cases to handle and the desired behavior is potentially different depending on the use case I'm wondering if symlink handling should be left out of Dandelion all together. Could you accomplish your desired symlink setup with a larger deploy process/script (part of which would be a dandelion deploy)?

dphoyes commented 9 years ago

For me, dandelion is a tool which allows me to perform the equivalent of a remote git checkout on servers where running git directly is not permitted. Since the behaviour of a true git checkout is to preserve links as this changeset does, I would consider dandelion incomplete if it didn't do the same. Any alternative, non git-like behaviours would possibly be better placed in a separate deployment tool, since it wouldn't need knowledge of the git repository and would have little overlap with what dandelion does.

I guess it's a bit trickier for adapters which don't allow symlinks. Since I don't have a personal use case for the S3 adapter, it's hard to say for sure, but I'd suggest that a project which uses S3 for deployment is unlikely to make use of symlinks, so a no-op (with a printed warning) is probably sufficient.

If it turns out that someone has a use for symlinks with incompatible adapters, another possibility is to simply upload a placeholder plain-text file for each symlink (containing the linked path, similar to dandelion's early behaviour), maybe with a '.dandelion-symlink' extension added. Then, any post-processing script would at least be able to see what the symlinks would have pointed to, and make any desired corrections.

dphoyes commented 7 years ago

Sorry to dig this up again, but I've made another attempt at this!

Fixed an issue where re-uploading a symlink with the same name but different target caused a failure
Stripped out the old handling of symlinks. Symlink preservation becomes compulsory, and the parameter to control this behaviour is now removed.
Only the SFTP adapter actually supports uploading symlinks. Any adapter which has no 'symlink' method will skip any attempt to create a symlink, and print out a message to indicate this. The message gives details of the symlink path and target in case someone wants to scrape this information and create the links manually.

Please let me know if there's anything I can improve.