edalize
edalize copied to clipboard
olofk
Introduce 'File' domain object
Allow clients to pass information about files either as File objects
or as dictionaries (legacy).
Using File objects makes it easier for clients to pass information about files.
It allows us to add validation rules in the future (e.g. name has to be a path - this immediately makes me realize it should have been called path instead of name). It also simplifies the code.
I've left the possibility to specify files as dictionaries, for backward compatibility reasons.
It's probably a good idea at this point to turn File into a proper class. But I'm not sure if you mean that we should pass File objects through the EDAM API as well? It kind of looks like that in the code, but that won't work since the EDAM API is supposed to be language-agnostic so that you can create EDAM files in any language
edalize is a Python library, which you call from Python code. Code that uses edalize will eventually call Edatool.__init__, which expects an edam parameter. The edam parameter is currently a dict, which (ideally) contains a files key, with a list value. Instead of expecting the user to supply a list of dictionaries, where each dict represents a file, the user could construct a list of File objects.
When you say "you can create EDAM files in any language", do you mean that it's possible to serialize an EDAM object to a file on disk? If so, the Python deserialization routine that constructs an EDAM object can use the File class.