Skip to content
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

Add skip_deps=AppListSeparatedByCommas feature #293

Closed
wants to merge 1 commit into from
Closed

Add skip_deps=AppListSeparatedByCommas feature #293

wants to merge 1 commit into from

Conversation

motiejus
Copy link
Contributor

@motiejus motiejus commented Aug 9, 2012

If skip_deps=comma,separated,app,list, then only specified dependencies are skipped.

@ghost
Copy link

ghost commented Sep 21, 2012

I think we should try to fix the skip_deps problem (tracked in #303) properly instead. @dizzyd @joewilliams?

@ghost ghost self-assigned this Sep 21, 2012
@dizzyd
Copy link
Contributor

dizzyd commented Oct 20, 2012

I think I'm ok with the concept; it's a useful tweak.

@lukyanov
Copy link

+1 for the feature. I have dependencies that are known to fail on eunit tesing and I'm ok with that (they are badly implemented in a way that the tests require some external services up, for example). Skipping those would be a good solution in some cases.

@ericbmerritt
Copy link
Contributor

This may be a good interim fix, but I don't think that its the right long term fix. The problem is not with this match but with the skip_deps feature itself. It seems to me that the common case is the non-recursive case rather then the recursive case. That is the default should be not to recurse at all and then have an option when you want to recurse. I have seen several proposals for a -r/--recursive with --recursive=<apps> option. Those are probably where effort should be concentrated.

@lukyanov
Copy link

Well, non-recursive behavior might be a good thing for some cases, but not
as default behavior, to my mind.
It would be strange if, for example, such a commonly used thing as "rebar
compile" didn't do recursive calls.
You checkout an application, run "rebar compile" (meaning to compile the
whole application), and you still don't get a working app.

On Tue, Oct 30, 2012 at 6:09 PM, Eric Merritt notifications@github.comwrote:

This may be a good interim fix, but I don't think that its the right long
term fix. The problem is not with this match but with the skip_depsfeature itself. It seems to me that the common case is the non-recursive
case rather then the recursive case. That is the default should be not to
recurse at all and then have an option when you want to recurse. I have
seen several proposals for a -r/--recursive with --recursive=option. Those are probably where effort should be concentrated.


Reply to this email directly or view it on GitHubhttps://github.com//pull/293#issuecomment-9906811.

@ericbmerritt
Copy link
Contributor

You can't checkout and application and run rebar compile and have it work anyway. Its always a git clone, then a rebar get-deps and finally a rebar compile and then you have a working app. The thing is you never want to do a recursive anything again after that not even a compile. I would much rather do a rebar -r get-deps compile then have to add skip_deps to every single command like I do now.

Right now I have to have a makefile to drive rebar so I can avoid all that extra typing.

dizzyd added a commit that referenced this pull request Nov 1, 2012
Add skip_deps=AppListSeparatedByCommas feature.

I agree it's a bit of a weird thing, but it's a reasonable and safe extension. When time comes to properly overhaul stuff, skip_deps should disappear entirely.
@dizzyd dizzyd merged commit 6eb7c08 into basho:master Nov 1, 2012
@dizzyd dizzyd closed this Nov 1, 2012
wcy123 pushed a commit to wcy123/rebar that referenced this pull request Mar 3, 2016
Check C source dependencies in needs_compile
wcy123 pushed a commit to wcy123/rebar that referenced this pull request Mar 3, 2016
wcy123 pushed a commit to wcy123/rebar that referenced this pull request Mar 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants