-
-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional dependencies? #28
Comments
Sure - just need to decide how best to do that with rebar. Suggestions are welcome. :) |
A lot of people do this by having multiple rebar configs — the main one being the leanest — and for dev/test they have rebar.dev.config, rebar.test.config, etc. Seems to work pretty well! |
I have pushed an implementation for this in the Feuerlabs fork of gproc: If this is acceptable, I can push it to the main repos. |
seems okay, a little bit convoluted to my personal taste, but as long as rebar won't build those deps by default, it's all fine |
For this particular use case, I agree it's a bit convoluted, but I noticed I end up needing dynamic dependency handling in other apps as well, so I am shooting for a reasonably generic approach. |
Either way, I think it is a desirable change that would be nice to have in this repo. |
Ok then - pushed to HEAD in the uwiger/gproc and esl/gproc repos. |
Quick question — have you considered making dependencies optional? Ideally both, but at least edown — it is definitely not needed by projects that use gproc. Also, gen_leader might be optional as not everybody uses gproc_dist.
Thoughts?
The text was updated successfully, but these errors were encountered: