Closed noonat closed 8 years ago
What do you think about making it --trash
and using send2trash? Else it's another parameter which takes a target path. I think the interface is cleaner. Loses some flexibility but addresses 99% of the use cases I think.
I don't think it would need a target path... to use the example from the readme, if this command does an import by copying:
./elodie.py import --source="/where/my/photos/are" --destination="/where/i/want/my/photos/to/go"
Then this would do an import and move the files instead of copying (that is, pass move=True to process_file):
./elodie.py import --move --source="/where/my/photos/are" --destination="/where/i/want/my/photos/to/go"
Trashing seems fine, though... I guess that leaves a copy behind of the original in case something goes horribly wrong?
@noonat I understand now. I would prefer --trash
since it leaves the file intact. There are other places where we perform a move and I think we're better off doing a copy and then a move to trash.
Created a branch for this, and it seems to work well! I'll hold off on opening a pull until the source/file changes are merged, since they stomp on each other.
Hey,
Is this feature in the latest release [yet] - I'd love to try it?
Hope to hear back
Cheers
@ldexterldesign looks like this was merged in gh-72. Let us know how it works.
@jmathai works well - no issues so far
Kind thanks
I would like my
elodie.py import
to move the files that Elodie supports, so I know that the files left over are ones I need to do something else with. Would you be open to a pull request that adds an optional--move
parameter toelodie.py import
? This would default to false to preserve the existing copy behavior.