Warning message if BRIDGESTAN is not defined about bridgestan

[WardBrian]

Hi -

Can you clarify what you would like to see addressed in this issue?

[goedman]

The minor issue is simple. Given that cmdstan and bridgestan are related, my suggestion is to call both makefile-s by the same name.

The first question is much harder to answer. Maybe it is possible to delay the check (get_bridgestan()) until later. Currently it is called in init() of BridgeStan.jl which prevents StanSample.jl (or another package that would like to include BridgeStan as a subtree) to define BRIDGESTAN before the library is actually used..

[sethaxen]

get_bridgestan itself doesn't throw the warning. Just __init__ does. What if get_bridgestan was changed to:

function get_bridgestan()
    path = get(ENV, "BRIDGESTAN", nothing)
    path === nothing && throw(ErrorException("BridgeStan path was not set, compilation will not work until you call `set_bridgestan_path!()`"))
    return path
end

This waits to check that BRIDGESTAN is set until it's needed. And since it's needed, instead of logging a warning, an error is thrown if it's not available.

[bob-carpenter]

Hi, Rob (@goedman): The plan is to factor out the dependency of BridgeStan on CmdStan's makefiles with the next Stan release. That is, we don't want someone to have to deal with any aspect of CmdStan in order to use BridgeStan. The main application we see is algorithm development.

I'm also not inclined to move this project to the Stan-dev org, because I don't want to be governed by community voting on interfaces. I've been outvoted on all of our interfaces in the past, so I'd prefer to keep this one outside of that process.

[sethaxen]

I'm also not inclined to move this project to the Stan-dev org, because I don't want to be governed by community voting on interfaces. I've been outvoted on all of our interfaces in the past, so I'd prefer to keep this one outside of that process.

@bob-carpenter this is a change of topic, but I was just trying to get PosteriorDB.jl transferred to the stan-dev org so it could live with the other posteriordb interfaces. Would you advise against that?

[bob-carpenter]

I was just trying to get PosteriorDB.jl transferred to the stan-dev org so it could live with the other posteriordb interfaces. Would you advise against that?

Not at all. That makes sense to roll into posteriordb, especially if you're happy with their interface. That way, other people will help maintain it. Mainly, I wanted to keep BridgeStan out of stan-dev until it was fully formed so I didn't have to negotiate interfaces. We might then roll it into the project. That's what Måns Magnusson did with posteriordb itself and what Paul Bürkner did with brms (and that still isn't on Stan-dev).

[WardBrian]

I think throwing an error in the compile methods rather than a warning at load is a good idea. The same probably goes for the Python interface.

[WardBrian]

Re: makefile vs Makefile, I agree with the recommendation GNU make has for Makefile (mainly that it stands out)

[goedman]

Thanks a lot for fixing this so quickly!!!!