[erlang-questions] "official" pre-built rebar binaries
Motiejus Jakštys
this is how I used to start my Erlang project Makefiles:
REBAR ?= ./rebar
REBAR_URL ?= https://github.com/downloads/basho/rebar/rebar
./rebar:
erl -noshell -s inets start -s ssl start \
-eval 'httpc:request(get, {"$(REBAR_URL)", []}, [], [{stream,
"./rebar"}])' \
-s inets stop -s init stop
chmod +x ./rebar
It worked fine and such, but for a new project I need a newer rebar.
Would it be possible to have a more recent pre-built "official" rebar
in an "official" repository?
Suggestion: create a rebar binary for every tag. Compile it on a
lowest supported platform (R13B04?), and put the resulting binaries
like this:
https://github.com/downloads/rebar/rebar/rebar-2.0.0
https://github.com/downloads/rebar/rebar/rebar-2.1.0-pre
--
Motiejus Jakštys
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Loïc Hoguin
> Hi,
>
> this is how I used to start my Erlang project Makefiles:
>
> REBAR ?= ./rebar
> REBAR_URL ?= https://github.com/downloads/basho/rebar/rebar
>
> ./rebar:
> erl -noshell -s inets start -s ssl start \
> -eval 'httpc:request(get, {"$(REBAR_URL)", []}, [], [{stream,
> "./rebar"}])' \
> -s inets stop -s init stop
> chmod +x ./rebar
>
> It worked fine and such, but for a new project I need a newer rebar.
> Would it be possible to have a more recent pre-built "official" rebar
> in an "official" repository?
>
> Suggestion: create a rebar binary for every tag. Compile it on a
> lowest supported platform (R13B04?), and put the resulting binaries
> like this:
> https://github.com/downloads/rebar/rebar/rebar-2.0.0
> https://github.com/downloads/rebar/rebar/rebar-2.1.0-pre
Github just announced that they removed support for file upload though.
https://github.com/blog/1302-goodbye-uploads
--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu
Motiejus Jakštys
> On 12/13/2012 05:34 PM, Motiejus Jakštys wrote:
>
> Github just announced that they removed support for file upload though.
>
> https://github.com/blog/1302-goodbye-uploads
Oh what a bad news, pity. However, if community and basho guys agree
with the concept, maybe it could be hosted somewhere in basho?
Or still is it still seen as the best practice to bundle rebar in the
repository or trust the user to have one and it's just me against
having binary stuff in the repository?
--
Motiejus Jakštys
Tuncer Ayaz
> Hi,
>
> this is how I used to start my Erlang project Makefiles:
>
> REBAR ?= ./rebar
> REBAR_URL ?= https://github.com/downloads/basho/rebar/rebar
Dizzy usually puts a new binary per release in the wiki by
calling 'make binary':
REBAR_URL ?= https://raw.github.com/wiki/rebar/rebar/rebar
> ./rebar:
> erl -noshell -s inets start -s ssl start \
> -eval 'httpc:request(get, {"$(REBAR_URL)", []}, [], [{stream,
> "./rebar"}])' \
> -s inets stop -s init stop
> chmod +x ./rebar
>
> It worked fine and such, but for a new project I need a newer rebar.
> Would it be possible to have a more recent pre-built "official" rebar
> in an "official" repository?
>
> Suggestion: create a rebar binary for every tag. Compile it on a
> lowest supported platform (R13B04?), and put the resulting binaries
> like this:
> https://github.com/downloads/rebar/rebar/rebar-2.0.0
> https://github.com/downloads/rebar/rebar/rebar-2.1.0-pre
Jachym Holecek
> On Thu, Dec 13, 2012 at 5:37 PM, Lo?c Hoguin <es...@ninenines.eu> wrote:
> >
> > Github just announced that they removed support for file upload though.
> >
> > https://github.com/blog/1302-goodbye-uploads
>
> Oh what a bad news, pity. However, if community and basho guys agree
> with the concept, maybe it could be hosted somewhere in basho?
>
> Or still is it still seen as the best practice to bundle rebar in the
> repository or trust the user to have one and it's just me against
> having binary stuff in the repository?
out of convenience, but it could hardly be considered best practice from
technical point of view -- due to ERTS' compatibility contract on BEAM
bytecode versions by including pre-built rebar we also implicitly dictate
the maximum Erlang version that will be able to build our project. If we
were to ever upgrade the pre-built rebar file we'd on the other hand
dictate minimum supported Erlang version.
Probably not what anybody really wants in the long run, I suppose?
Perhaps best to require rebar as a build-time dependency if you want
to play safe?
BR,
-- Jachym
Motiejus Jakštys
> On Thu, Dec 13, 2012 at 5:34 PM, Motiejus Jakštys wrote:
>> Hi,
>>
>> this is how I used to start my Erlang project Makefiles:
>>
>> REBAR ?= ./rebar
>> REBAR_URL ?= https://github.com/downloads/basho/rebar/rebar
>
> Dizzy usually puts a new binary per release in the wiki by
> calling 'make binary':
> REBAR_URL ?= https://raw.github.com/wiki/rebar/rebar/rebar
This is better. But how does the file get there? I cannot find how to
add a file to the github wiki.
Any thoughts about binary versioning ("my project works with rebar
2.0, don't know about rebar 2.1").
--
Motiejus Jakštys
Tuncer Ayaz
> This is better. But how does the file get there? I cannot find how to
> add a file to the github wiki.
Motiejus Jakštys
> On Thu, Dec 13, 2012 at 5:59 PM, Motiejus Jakstys wrote:
>
>> This is better. But how does the file get there? I cannot find how to
>> add a file to the github wiki.
>
> https://github.com/rebar/rebar/blob/71c717d8/Makefile#L30-L33
Oh, didn't realize that. Thanks. So we have a way, now need (?) to
agree on the rules. Any more people believe it is necessary?
--
Motiejus Jakštys