wojtekmach / hex_tar

Replaced by https://github.com/hexpm/hex_erl.

hex_tar's Issues

Metadata format

Right now hex_tar:create and hex_tar:unpack works with the metadata in the following format:

    Meta = [
            {app, <<"foo">>},
            {name, <<"foo">>},
            {version, <<"1.0.0">>},
            {description, <<"description">>},
            {build_tools, <<"rebar3">>},
            {files, [<<"foo.erl">>, <<"bar.erl">>]},
            {licenses, [<<"Apache 2.0">>]},
            {requirements, [
                            {<<"bar">>,
                             [
                              {app, <<"bar">>},
                              {optional, false},
                              {requirement, <<"~> 0.1">>}
                             ]
                            }
                           ]},
            {links, {<<"GitHub">>, <<"https://github.com/hexpm/foo">>}}
           ],

(https://github.com/wojtekmach/hex_tar/blob/b319442f50fcc452ba54593113b1ce35d08eae02/test/hex_tar_tests.erl)

This is almost exactly the same as https://github.com/hexpm/specifications/blob/master/package_metadata.md, the only difference is we use atom keys instead of binary keys as in the spec.

The problem is that it's not quite the same as in either spec or how hex and hexpm uses it. We want to expose a format that will be convenient to use by existing and future tooling, as well as folks playing with the tarballs like in https://github.com/wojtekmach/hex_tar/blob/master/README.md#example.

Options

I think we have these options:

1. above. Pros: atoms imply "safe" keys, looks nice in Elixir (because keyword)

2. 1., except use binaries. Pros: exactly the same as per spec

3. 1., except represent requirements as:

   [{app, <<"bar">>}, {requirements, #{"foo" => #{app => "foo", ...}}}]

   This is what rebar3_hex does. ⚠️ it stores maps into metadata.config which is against spec.

4. maps with atom keys and requirements as:

   #{app => "bar", requirements => [#{app => "foo", name => "foo", ...}]}

   This is what Mix.Tasks.Hex.prepare_package returns (and Hex.Tar.create takes)

5. above, but with binary keys. This is what Hexpm.Web.ReleaseTar.metadata returns

6. maps with atom keys and requirements:

   #{app => <<"foo">>, requirements => #{<<"bar">> => #{app => "bar", ...}}}

   Pros: I guess closer to spec

The downside of using maps is that they're unordered so we'd need to do extra work to keep them in order when persisting into metadata.config so that it's reproducible.

I think all options are viable, personally I like 6 the most. Thoughts?