CAN ANYONE HELP ME ON THIS

[Shoreshen]

Processing archive: C:\Users\shoren\.julia\v0.4\MbedTLS\deps\downloads\mbedtls-2.1.1-r1.zip

Error: Can not open file as archive

===============================[ ERROR: MbedTLS ]===============================

LoadError: failed process: Process(`7z x 'C:\Users\shoren\.julia\v0.4\MbedTLS\deps\downloads\mbedtls-2.1.1-r1.zip' -y '-oC:\Users\shoren\.julia\v0.4\MbedTLS\deps'`, ProcessExited(2)) [2]
while loading C:\Users\shoren\.julia\v0.4\MbedTLS\deps\build.jl, in expression starting on line 69

================================================================================

================================[ BUILD ERRORS ]================================

WARNING: MbedTLS had build errors.

 - packages with build errors remain installed in C:\Users\shoren\.julia\v0.4
 - build the package(s) and all dependencies with `Pkg.build("MbedTLS")`
 - build a single package by running its `deps/build.jl` script

================================================================================

[wildart]

Don't panic. If you read error carefully, you'll find that extraction from the archive has failed, i.e. 7z x ....

• install 7-zip file archiver (http://www.7-zip.org/)
• make sure that 7z command is available in the command line
• run `Pkg.build("MbedTLS")

[Shoreshen]

thanks for your help. I installed 7-zip, i do not know how to verify the 7z command. my system is win10, the problem persist.........

ima 100% new to julia, so kind of dont know what to do....

[Shoreshen]

well I installed 7-zip, deleted other zip programs. 7-zip can run in cmd. but.... the problem persist......

[wildart]

Try to run 7z command in julia command line mode. It is possible that 7z program location is not visible from the command line. You can add this location to PATH environmental variable. If the problem persist, please open issue with BinDeps package.

[tkelman]

Most likely the download is corrupt. Delete C:\Users\shoren\.julia\v0.4\MbedTLS\deps\downloads\mbedtls-2.1.1-r1.zip then try re-running Pkg.build("MbedTLS") again. Didn't you post this same thing on julia-users or in a different repository? Please only post one place, or at a very minimum add cross-links between the posts.

[Shoreshen]

yep i deleted the file and re build it. it works. sorry for the double post for this and another issue. ill post only 1 place next timo:)

[tkelman]

Strange that there's even a checksum provided for that file here, which I would think should have automatically caught the issue. @staticfloat you're probably the person most familiar with how the BinDeps checksumming works (or is supposed to), any ideas?

[staticfloat]

Oh yikes, the keyword argument is supposed to be SHA, but instead it's written here as sha. Not sure what we should do about that. I don't think changing BinDeps to error out on incorrect kwargs is the right response, that will probably cause massive breakage. Maybe we should just map in sha as well as SHA right here and here?

[tkelman]

oh good catch - yeah I think accepting both capitalizations in BinDeps would be the least error prone thing to do

[nalimilan]

I don't like the idea of supporting two different case variants. The problem is more general anyway: any typo in the name of an argument will give silent failures. It would be much better to print a warning when an unknown argument is encountered. After a deprecation period, they could be turned into errors.

[tkelman]

That wouldn't be a bad idea either, but someone has to collect a list of every single accepted option argument in bindeps, write a validator function and decide where to run it, then make sure the master list of possible keyword arguments is prominent enough that everyone remembers to update it.

[nalimilan]

Sure, that's a bit more work, but if we introduce sha now, we'll have to go through a painful deprecation process to get rid of the duplication of arguments later.

[wildart]

I agree, multiple names for one option is a bad idea. Need to fix MbedTLS build script, and not BinDeps, even though chose of the name was unfortunate.

[tkelman]

Lower case is more idiomatic for a Julia keyword argument. Exactly what is the harm of accepting either? If it's a mistake that multiple people are likely to make, and neither of you are about to write a keyword argument warning checker, I'm for being more permissive.

[wildart]

I would not want to encourage different parameter naming especially when there is no checks on which name is accepted. Next person will decide that Sha option is ok. Why not? There are already two spellings.

[nalimilan]

I agree that the lower case is more idiomatic. So we could aim at deprecating the upper case version instead.

[tkelman]

I think people are less likely to write Sha by accident. Either we should check for unrecognized arguments, or do the intuitive thing for now.

[wildart]

Checking for correct option pretense must be done as well.

!haskey(opts, :sha) && warn("No `sha` option provided") # or error

[staticfloat]

We don't want to force people to provide a sha hash for every download; there are plenty of downloads that you may not care about enough to verify package integrity. I will write an option validator; there are only really 5-6 keyword arguments you can pass to a BinDeps provider anyway.

[nalimilan]

For reference, see JuliaPackaging/BinDeps.jl#221 regarding keyword arguments validation.