Skip to content
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

no method matching open(::Void, ::String) #66

Closed
omus opened this issue Aug 17, 2018 · 6 comments
Closed

no method matching open(::Void, ::String) #66

omus opened this issue Aug 17, 2018 · 6 comments

Comments

@omus
Copy link
Contributor

omus commented Aug 17, 2018

ERROR: LoadError: MethodError: no method matching open(::Void, ::String)
Closest candidates are:
  open(::AbstractString, ::AbstractString) at iostream.jl:132
  open(::Function, ::Any...) at iostream.jl:150
  open(::Base.AbstractCmd, ::AbstractString) at process.jl:575
  ...
Stacktrace:
 [1] open(::SHA.#sha2_256, ::Void, ::String) at ./iostream.jl:150
 [2] run_checksum(::Tuple{SHA.#sha2_256,String}, ::Void) at /Users/omus/.julia/v0.6/DataDeps/src/verification.jl:22
 [3] checksum_pass(::String, ::Void) at /Users/omus/.julia/v0.6/DataDeps/src/resolution_automatic.jl:111
 [4] #download#19(::String, ::Void, ::Bool, ::Function, ::DataDeps.DataDep{String,String,##3#4,Base.#identity}, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution_automatic.jl:51
 [5] handle_missing(::DataDeps.DataDep{String,String,##3#4,Base.#identity}, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution_automatic.jl:8
 [6] _resolve(::DataDeps.DataDep{String,String,##3#4,Base.#identity}, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution.jl:83
 [7] resolve(::DataDeps.DataDep{String,String,##3#4,Base.#identity}, ::String, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution.jl:31
 [8] resolve(::String, ::String, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution.jl:54
 [9] resolve(::String, ::String) at /Users/omus/.julia/v0.6/DataDeps/src/resolution.jl:73
 [10] include_from_node1(::String) at ./loading.jl:576
 [11] include(::String) at ./sysimg.jl:14
 [12] process_options(::Base.JLOptions) at ./client.jl:305
 [13] _start() at ./client.jl:371
while loading /Users/omus/.julia/v0.6/.../test/runtests.jl, in expression starting on line 13
@omus
Copy link
Contributor Author

omus commented Aug 17, 2018

I'll note if I re-run it appears as if everything is fine and doesn't re-attempt to download the files which it is missing.

@oxinabox
Copy link
Owner

oxinabox commented Aug 18, 2018

Could you post the triggering code?

Re:that it doesn't attempt a re-download if it errors out.
I'll push a patch for that this afternoon.
That has bugged me for a while, and the solution is to do some cleanup before rethrowing the error.

@oxinabox
Copy link
Owner

I can't reproduce this error with the DataDeps.jl tests in 0.6.
So I am guessing this is in your own project.
Can you post a MWE?

Speculation follows:

You are using a custom fetch_method right?
If I am reading
DataDep{String,String,##3#4,Base.#identity}
correctly that ##3#4 is an anon function.

And this anon function returns nothing?
As shown by checksum_pass(::String, ::Void) being called.

As of #54 this is no long allowed.
So your custom function (if I have worked this right) should be changed to return a filename.

@omus
Copy link
Contributor Author

omus commented Aug 21, 2018

You are correct: the fetch_method wasn't returning a filename

@omus
Copy link
Contributor Author

omus commented Aug 21, 2018

I won't be able to post the triggering code as is as it involves some private packages. I'll try to post a MWE soon (probably at the end of the week)

@oxinabox
Copy link
Owner

I could add a check at:

localpath = fetch_method(remotepath, localdir)

That localpath was an AbstractString, or else give an informative error message.
This would work both for paths defined using the normal String way,
and for FilePathsBase.jl since that subtypes AbstractString.
I find it a little subideal as I don't entirely feel that AbstractString is the best type for paths.
But right now it is the only type used for paths, so I could always fix that later if some one raises an issue.

What looks like a solution but isn't (recording this so I don't go through this incorrect line of thought)
is to read from the file systems the path after

fetched_path = run_fetch(datadep.fetch_method, remotepath, localdir)

in order to set fetched_path.
However, this is not doable, as the order needs to be maintained for purposes of the recursive handling of checksums and post_fetch_methods.
(Longer term restructuring those might be a good idea, into a array of struct, rather than struct of arrays kinda deal. Which would also make doing more stuff in async possible, with some thought.)

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

No branches or pull requests

2 participants