Push latest version to Hex.pm about erlang-lz4 HOT 24 CLOSED

I think @tinglei8 published the repo on hex.pm...

from erlang-lz4.

@lpgauth Hi I'll try to push 0.2.4... pretty busy recent days...
btw you can also work around by using mix local deps like {:lz4, path: "deps/lz4" }, work well in my project

from erlang-lz4.

@tinglei8 thanks

Unfortunately, I need this version on hex.pm so I can publish marina on hex.pm.

from erlang-lz4.

@lpgauth Hi, I just pushed 0.2.4 to hex.pm.

from erlang-lz4.

@tinglei8 thanks!

from erlang-lz4.

Hi @tinglei8,
It looks like you also pushed the .o which you shouldn't.

To correct this you need to whitelist the files you want to publish.

e.g. https://github.com/tokenrove/granderl/blob/master/src/granderl.app.src#L8

packages$ tar -xvf contents.tar.gz
x c_src/Makefile
x c_src/lz4.c
x c_src/lz4.h
x c_src/lz4.o
x c_src/lz4_nif.c
x c_src/lz4_nif.o
x c_src/lz4hc.c
x c_src/lz4hc.h
x c_src/lz4hc.o
x c_src/lz4opt.h
x src/lz4.app.src
x src/lz4.erl
x test/lz4_tests.erl
x README.md
x CHANGES
x rebar.config

@tsloughter @ferd can we make rebar3 automatically filter object files or at least warn against this?

from erlang-lz4.

@lpgauth Sorry for that, I can publish again.

It seems there isn't a "excluding file" feature for hex: erlef/rebar3_hex#25

So I just added a few inclusion rules in tinglei8@dd5e054

Any idea for another version name to follow 0.2.4?

from erlang-lz4.

I have published using version number "0.2.4-a", but it's sorted to a position after 0.2.4 on hex.pm, and can only be downloaded by using {:lz4, "0.2.4-a"}.

Seems to totally get rid of all *.o in latest version we have to wait for 0.2.5 release.

from erlang-lz4.

@lpgauth I don't want to automatically filter specific types of files. But I am planning to add an "exclude" option to hex. Just have to find the time :(

from erlang-lz4.

mix get 0.2.4 from hex, please update and publish to hex as 0.2.5 version

from erlang-lz4.

In theory @tsloughter or @ferd can delete the 0.2.4 release so that you can re-publish it

from erlang-lz4.

I think hex's way suggests that if you made mistake in publishing hex versions, you bump the version to fix it (as soon as possible). @szktty would you like to bump version to 0.2.5, just for fix of the hex package?

from erlang-lz4.

I was using cassandra, and when I updated lz4 today I got a compile error, due to this issue (having .o files pushed).

I could not switch to 0.2.4-a because it conflicts with ecto_cassandra.

Manual fix for compiling, until repo is fixed, is to do rm deps/lz4/c_src/*.o.

I was using edeliver to build releases, and it failed. This is the hook I used to get a release:

pre_erlang_clean_compile() {
  status "Fixing lz4 0.2.4 compile error"
  __sync_remote "
    [ -f ~/.profile ] && source ~/.profile
    set -e
    cd '$BUILD_AT'
    rm deps/lz4/c_src/*.o
  "
}

from erlang-lz4.

@vfsoraki

also you can add these lines to your app mix file

# Type `mix help deps` for examples and options.
  defp deps, do: [
      {:lz4, github: "szktty/erlang-lz4", override: true},
    ]

from erlang-lz4.

@alirajabi Thanks!

It was compiling, but I had strange errors when running release. It is working now.

from erlang-lz4.

There actually is an "exclude" option in the Hex plugin (I added it). Obviously, it was poorly documented. I'd be happy to follow up on suggestions for where documentation would be helpful.

At least now it's mentioned with an example on http://www.rebar3.org/docs/publishing-packages

from erlang-lz4.

Any ideas why it keeps re-pulling this dep? @ferd @tsloughter

lpgauth marina (feature/hex-pm)$ ./bin/rebar3 upgrade
===> Verifying dependencies...
===> Upgrading lz4 ({pkg,<<"lz4">>,<<"0.2.4-a">>,
                                <<"D46A8AA7BD7AB0A9877F127CEBD95A24B8491066D0D2135D757C1601E87AC53E">>})
===> Downloaded package, caching at /Users/lpgauth/.cache/rebar3/hex/default/packages/lz4-0.2.4-a.tar
===> Upgrading lz4 ({pkg,<<"lz4">>,<<"0.2.4-a">>,
                                <<"D46A8AA7BD7AB0A9877F127CEBD95A24B8491066D0D2135D757C1601E87AC53E">>})
===> Downloaded package, caching at /Users/lpgauth/.cache/rebar3/hex/default/packages/lz4-0.2.4-a.tar
===> No upgrade needed for shackle
===> No upgrade needed for granderl
===> No upgrade needed for metal
lpgauth marina (feature/hex-pm)$ ./bin/rebar3 upgrade
===> Verifying dependencies...
===> Upgrading lz4 ({pkg,<<"lz4">>,<<"0.2.4-a">>,
                                <<"D46A8AA7BD7AB0A9877F127CEBD95A24B8491066D0D2135D757C1601E87AC53E">>})
===> Downloaded package, caching at /Users/lpgauth/.cache/rebar3/hex/default/packages/lz4-0.2.4-a.tar
===> Upgrading lz4 ({pkg,<<"lz4">>,<<"0.2.4-a">>,
                                <<"D46A8AA7BD7AB0A9877F127CEBD95A24B8491066D0D2135D757C1601E87AC53E">>})
===> Downloaded package, caching at /Users/lpgauth/.cache/rebar3/hex/default/packages/lz4-0.2.4-a.tar
===> No upgrade needed for shackle
===> No upgrade needed for granderl
===> No upgrade needed for metal

from erlang-lz4.

Usually means the version found in the lock file isn't matching what it finds in the .app under _build after fetching/building.

Can't be positive that is the issue here but that is usually what I've seen with rebar3 re fetching when I knew it had already fetched a dep.

from erlang-lz4.

OK so the hex package defined in the rebar.config:

{deps, [
  {lz4, "0.2.4-a"},
  {shackle, "0.5.1"}
]}.

needs to match the *.app.src

marina (feature/pool)$ cat _build/default/lib/lz4/src/lz4.app.src  | grep vsn
  {vsn, "0.2.2"},

0.2.4-a != 0.2.2

@tsloughter maybe rebar3 should warn if you push the wrong version?

from erlang-lz4.

Yea, I'd have to know how it happened here to guard against it. Since it takes the version from the .app when publishing it shouldn't get the wrong one.

I think it mainly will happen if there is a ebin/ at the top level of a project with an old .app. This is a general issue with rebar3 not being able to know if the user actually wants to use the ebin/.app as their app file or if it is an accident :(

from erlang-lz4.

I'd say rebar3 should just ignore top level ebin/, but that causes a surprising number of complaints :(

from erlang-lz4.

Hi @szktty, could you bump the version in https://github.com/szktty/erlang-lz4/blob/develop/src/lz4.app.src#L4 to 0.2.5 and then @tinglei8 can push this new version on hex.pm? Otherwise I will have to implement yet another LZ4 nif...

from erlang-lz4.

Hi @lpgauth , I'm sorry for few responses. Would anyone like to maintenance this library instead of me? Now I have been not working with LZ4 and busy with other works. If a new maintainer or maintainers fork this, I do deprecate the repository and link to a new repository.

from erlang-lz4.

I'm happy to maintain a fork... but @tinglei8 controls the hex.pm package :/

from erlang-lz4.