What?
Why?
There are several reasons for this task:
- Functionality in ioSPI and simSPI should not be entangled. The fact that they are, i.e. simSPI is using ioSPI, complicates the development: as any PR on ioSPI potentially requires a refactoring PR on simSPI.
- Functionalities that download or upload data with OSF use different logics that are hard to grasp for newcomers: this task creates one Python class only, i.e. one single point of entry with one logic.
The library ioSPI can only be useful if users can understand it quickly. This task is urgent and very much needed.
Where?
The class OSFProject should go into the ioSPI/datasets.py module.
This class replaces the classes Project and OSFUpload from ioSPI/datasets.py.
How?
The new class OSFProject should have (at least):
- a method
ls: listing the files of a OSF project
- a method
download
- a method
upload
and follow the logic that one object instantiated from this class corresponds to one OSF project.
What?
OSFProjectin ioSPI/datasets.py that refactors the code in:Projectin ioSPI's PR#70OSFUploadin ioSPI/datasets.py moduleupload_dataset_from_filesof simSPI's tem_tutorial.ipynbupload_dataset_from_filesof simSPI's tem_tutorial.ipynbdatasets.pymodule.Why?
There are several reasons for this task:
The library ioSPI can only be useful if users can understand it quickly. This task is urgent and very much needed.
Where?
The class
OSFProjectshould go into the ioSPI/datasets.py module.This class replaces the classes
ProjectandOSFUploadfrom ioSPI/datasets.py.How?
The new class
OSFProjectshould have (at least):ls: listing the files of a OSF projectdownloaduploadand follow the logic that one object instantiated from this class corresponds to one OSF project.