How do I generate only a single release
watson.timothy at gmail.com
Fri Apr 6 14:44:41 EDT 2012
On 5 April 2012 18:14, David Smith <dizzyd at basho.com> wrote:
>> (*) the source code is very hard to follow. Who thought it was a good
>> idea to use the process dictionary to keep track of commands and
>> signal failures further up the chain? If I rewrite rebar to stop
>> using the process dictionary, will that patch be accepted (or are
>> there too many plugins that depend on the current behavior)?
> It was my idea, feel free to blame me. Improving it would certainly be
> a good thing. :)
I can imagine a few plugins breaking because of this change, but on
the other hand I think those plugins are often, at least in my
experience, trying to 'work around' the way that commands and/or
statuses are currently handled. If the list of commands and/or results
was 'passed around' (along with rebar_config?) then plugins and/or
internal APIs would have the opportunity to introspect these - which
is very useful - and perhaps even modify them (by adding, removing or
delaying commands to the pipeline) which would again, be very useful,
as would the ability for modules (of all sorts) to optionally modify
the rebar_config that is being passed around to everyone else.
I think the key thing we'd need to think about is that all rebar
modules, both 3rd party plugins and internal rebar modules for things
like compilation, testing and so on, use the same API:
(and the following articles expand on this discussion). If that API
changed, wouldn't it be a rewrite of *all* the rebar modules.
The safer candidate for 'refactoring' in my opinion would be
rebar_core, as one could leave the existing code alone providing the
'new' API allowed for sensible default behaviour. Now rebar_core on
the other hand, could potentially allow for alternative (or
additional) means of discovering internal/external plugin
functionality, instead of it having to be bound up in the list of
available exported functions from a known set of modules (see
At the moment the API is very simple, which as dizzy has pointed out
in the past, is probably a big part of the reason for rebar's success.
Could a richer API be made to work, without sacrificing this
simplicity? I'm wonder about having more data going into modules as
they execute commands, allowing modules to return a richer set of
instructions (or perhaps hints is a better word) not only about
directories they potentially care about, but commands as well. A
classic example of this would be this situation:
1. I need to build my project
2. My project requires custom code to be available and run before it is compiled
3. I need a plugin in order to provide the 'custom code' that is
needed prior to compilation
4. I use 'get-deps' to fetch the plugin, *but* I now have to 'compile'
the plugin before it can do it's work
5. I now have to 'compile' my code *again* and not only is this
onerous but this time I need to skip_deps use a different config set
So I end up with:
$ rebar -C init.config get-deps compile
$ rebar compile generate
But if the modules (such as plugins) involved in the first of these
two executions was able to say a bit more to rebar_core about what it
needed in order to work properly, we could cut it down to one command
(a) pre_generate: I want to run 'get-deps' and 'compile' using "./init.config"
(b) post_compile: I want to run 'compile' again, only on my main src
folders, not for deps, using "./rebar.config" this time, and I want to
dis-able this post_compile so it doesn't recurse infinitely
This kind of ability - to change config sets on the fly, use different
config sets for different commands, ask for additional commands to be
run or removed from the processing pipeline - allows for really
complex behaviour to be config driven. One can achieve most of it
today, but it requires really invasive hackery.
The upcoming file:script support proposed by Ulf looks very promising
for a large range of these requirements, but two key areas that
interest me require more structured (plugin based) support, which
would benefit greatly from some API enrichment:
1. the ability to share and re-use common configuration
2. the ability to modify the build lifecycle dynamically
So for I've been able to get 90% of my projects to work with two
$ rebar -C init.config get-deps compile
$ rebar skip_deps=true -C test.config clean test # this relies on
lots of customisations that get installed during the first command
I'd *really* like to be able to just do `rebar clean test` and have
everything magically work in between, based on *my* own configuration
so that only my expectations are met in terms of the semantics, driven
by the project level configuration. This carries the assumption that
"deps are just there to be compiled and not tested or anything else"
which is not how a lot of people are using them at the moment.
I hope that provides some interesting food for thought anyway.
More information about the rebar