Wojtek Mach

yeah let's raise early with an error about a specific k/v. if people complain that this creates a game of whack-a-mole, we could change the error to include the whole...

Let's hold off on those changes. I thought about it a little bit last night and my conclusion is we'll be doing changes like these: ```diff -hex_api_package:search(Config, , [{page, 1}])....

@ericmj do you have a preference whether we should allow atom or binary keys in params? I believe the advantage of atom keys is we can type spec them. What...

Good point. Let’s go with binary keys as originally stated. Thanks @ericmj!

We've introduced the function in https://github.com/hexpm/hex_core/pull/74, all that is left is the semver validation.

I guess we should have the same validation when _creating_ docs tarball.

``` mix hex.package fetch xclient 0.5.0-vendored-xhttp --unpack ** (Mix) Unpacking tarball failed: inner tarball error, no such file or directory ```

The packages are broken but hex_core should gracefully handle that.

> Otherwise I'd expect consistency: unpack({file, Name} | {binary, Bin}, ...) I was going for similar API to erl_tar: ```erlang extract(Name) -> RetValue Name = filename() | {binary,binary()} | {file,Fd}...

Somewhat related, we allow: 1. `hex_tarball:create(Metadata, ["foo.erl"]).` 2. `hex_tarball:create(Metadata, [{"foo.erl", "/path/on/disk/to/foo.erl"}]).` 3. `hex_tarball:create(Metadata, [{"foo.erl", }]).` Option 1. is a convenience inherited from erl_tar and I'd be ok with dropping it...