Skip to content

Avoid ambigous destination value in test case...#186

Merged
jmchilton merged 2 commits intogalaxyproject:masterfrom
peterjc:ambiguous_destination
May 7, 2015
Merged

Avoid ambigous destination value in test case...#186
jmchilton merged 2 commits intogalaxyproject:masterfrom
peterjc:ambiguous_destination

Conversation

@peterjc
Copy link
Contributor

@peterjc peterjc commented May 7, 2015

Suggestion: If the source has any wildcards (or is a folder with an implicit wildcard), then destination must be a directory given with trailing slash (otherwise error).

The include source of "../shared_files/extra_test_data/**" would only find "../shared_files/extra_test_data/extra_test_file.txt" which after strip_components 3 gives "extra_test_file.txt"

Question: did the ".shed.yml" destination of "test-data" mean call this file "test-data" [sic] or use "test-data/extra_test_file.txt" instead? Why?

What if the include source glob matches multiple files? Then might expect destination must be a folder - since alternative means trying to map multiple input files to one in the tar-ball/

Using destination "test-data/" seem unambiguous and preferable.

(I found this issue during re-factoring while working on #180)

The include source of "../shared_files/extra_test_data/**" would
only find "../shared_files/extra_test_data/extra_test_file.txt"
which after strip_components 3 gives "extra_test_file.txt"

Question: did the ".shed.yml" destination mean call this file
"test-data" [sic] or use "test-data/extra_test_file.txt" instead?

What if the include source glob matches multiple files? Then might
expect destination must be a folder?

Using destination "test-data/" seem unambiguous.
@peterjc
Copy link
Contributor Author

peterjc commented May 7, 2015

P.S. I am willing to try and add code to catch the proposed error condition.

@jmchilton
Copy link
Member

Okay - I can live with that - what you are proposing seems like a tighter, more reasonable spec. We should make sure shed_lint provides a good description of the problem though.

@peterjc
Copy link
Contributor Author

peterjc commented May 7, 2015

So changes to both shed_lint (new ground for me) and shed_upload (starting to understad) needed?

@jmchilton
Copy link
Member

If you return an exception - like unmatched globs - I think shed_lint will just print a message for it - so we should verify this but I don't think it will require changes to shed_lint.

Update: This line https://github.com/galaxyproject/planemo/blob/master/planemo/shed/__init__.py#L775 is what I was referring to about "returning" an exception.

I can definitely work on that part - the concept of "missing" needs to be generalized to other sorts of validation exceptions. But as long as we get them out of that chunk of code as exceptions shed lint should handle it.

jmchilton added a commit that referenced this pull request May 7, 2015
Avoid ambigous destination value in test case...
@jmchilton jmchilton merged commit 8f23885 into galaxyproject:master May 7, 2015
@jmchilton
Copy link
Member

Awesome - thanks for working on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants