Chris

I think one complication here is guaranteeing good behavior between dependencies. For example, if you give ffmpeg a dependency on x264, that means Needy should ensure that `x264` is built...

I want to facilitate this, but I don't think this is something I want to build directly into Needy. I'd rather do this in Jinja somehow, either through built-in functions...

Maybe all that's needed to facilitate this is just a more advanced loader: ``` libraries: {% with version="1.0.0" %} {% include "[email protected]:my-org/needy-recipes.git/openssl.yaml" %} {% endwith %} ```

Well, I don't think that syntax is gonna work. I'm not interested in making modifications or extensions to the Jinja language. My latter example has the really nice benefit of...

To avoid doing non-standard things with Git URIs and be a little more flexible, maybe it would be better to just create a git_include macro: libraries: {% with version="1.0.0" %}...

> I would be very happy if defining a macro wasn't required to have multiple versions of the library–that should be done with something that specializes in version control. Disagreement...

I think there may be some confusion over what my example `with` syntax does. The `version` there has no special meaning. It is just a Jinja way to pass variables...

Yeah though there are some questions of implementation... Should this really pull the most recent every time the template is rendered? Or should some sort of caching be done?

Yeah, the only difficulty would be in using a branch name. I don't think three parameters would be necessary though. We can easily tell after the first fetch what type...

I suppose the same problem is actually already present if you used a branch name as the needs commit as well. Perhaps in both cases, branch names should just be...