Provide support for submitting multiple files

[kytrinyx]

{
    "files": [
    {
      "filename": "path/to/file.ext",
      "code": "# code goes here...",
    },
  ]
}

See related issue: exercism/exercism#1165

[ClashTheBunny]

As a stop gap, you could allow for submitting multiple files with the command line client by concatenating the files provided on the command line with some sort of header (maybe specific to the language) that would then show up as a comment on the code display. This way there is no server side changes necessary for the short term.

[kytrinyx]

Yes, that would work.

[kytrinyx]

The backend supports accepting multiple files (see exercism/exercism#1165), so this one can be bumped to the top.

[lcowell]

Would the usage now be that I would specify multiple files from the command line eg:
exercism submit AbstractBobPresenter.java Bob.java

The Iteration struct, is what is used with client.Submit. Currently it has a File attribute, so we would need to change it to be a slice of Files and update the code that works with iterations to handle multiple files. Does that sound about right so far as what's involved in completing this?

[kytrinyx]

Would the usage now be that I would specify multiple files from the command line eg:

Yeah, that's what I was thinking.

Right now the API expects a JSON map of filename to contents. That would mean using a map[string]string serialized to json:"solution", but I could change it to expect the serialized []File if that seems cleaner.

It's a small change in one place, so really no big deal either way.

[ClashTheBunny]

Just to make sure, the the path of the file would be nice to preserve in
the metedata. Some languages give significance to deep directories.
On Jan 26, 2015 7:21 AM, "Katrina Owen" notifications@github.com wrote:

Would the usage now be that I would specify multiple files from the
command line eg:

Yeah, that's what I was thinking.

Right now the API expects a JSON map of filename to contents. That would
mean using a map[string]string serialized to json:"solution", but I could
change it to expect the serialized []File if that seems cleaner.

It's a small change in one place, so really no big deal either way.

—
Reply to this email directly or view it on GitHub
#35 (comment).

[kytrinyx]

Yeah, the path of the file is currently being preserved, and we need to continue to do so.

[kytrinyx]

Closed in #166