-
Notifications
You must be signed in to change notification settings - Fork 15
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
Directory importer #7
Conversation
First test done locally. It does what is says it would do. I certainly need more explanation about the |
@pwalczysko Because of the way the script works it would be possible with minor changes to ask the script to create P/D and S containers based on a text file, similar to the way the previous version did using |
Tested further locally. |
As discussed with @ximenesuk , the |
@pwalczysko I've added these options in the latest commits. |
Both options (-f and -n) work fine. Admittedly much less frequent case, but possible : how about creating a project with no datasets (and, obvously, no images) inside ? Possibly
|
@ximenesuk : prefer to have this merged before the general cleanup (i.e. file deletions, etc)? |
@joshmoore I would prefer this to be merged now and then maybe let @pwalczysko do the clean-up so that he has the configuration he needs. I'll add the use case mentioned above in a separate PR. |
Understood, and agreed. Merging. |
This PR adds a revised auto importer that uses a limited nested directory structure to create containers and initiate imports. An example directory is included though this should probably be changed to use fakes and add fake screens. A readme file describes the directory structure.
The intention here is to firstly allow different import scenarios by rsyncing data into place and then running the script, avoiding duplication of configuration files. Ultimately with proposed modifications to DropBox a simple rsync to the DropBox folder should have the same effect as running the script.