[erlang-questions] rebar3 dependencies

[Benoit Chesneau]

On Sat, Mar 19, 2016 at 8:30 AM Roberto Ostinelli <roberto@REDACTED>
wrote:

> Tristan, Fred, Eric
> First of all, let me very clear on this: I want to thank you for the work
> you're all doing. It is a tremendous amount of work, and I can only be
> grateful that you are willing to share it with me and the rest of the
> community. I know how hard it can be working in open source and receiving a
> variety of random requests, sometimes coming from people that "expect"
> things to get done by you. So: thank you.
>
> Now, to get back to my original question: Tristan, you say that releases
> "bundle all dependencies at a certain point in time", and that wanting to
> vendor dependencies is "unnecessary and poor form". I would like for you to
> consider that there are real cases for which vendoring is necessary, and
> not poor form. Let me give you some examples.
>
> 1. Even in the Ruby community, gems disappear - whatever the reason. It
> has happened before, it will happen again. Hex.pm, being smaller and way
> more recent, is also probably (at least now) less reliable than rubygems,
> and in general relying on github repositories for those libraries not yet
> packaged is even worse. It is therefore understandable that some may feel
> better knowing that they just have to rely on their own repository, where
> all dependencies have been vendored.
>
> 2. Releases "bundle" all dependencies at a certain point in time, as you
> say, but only with whatever exists at that time. I'd like to be able to
> release the same code on newer Erlang releases, sometimes years after my
> first release. Or with different operating systems. See point 1: I need to
> ensure to have all the dependencies in my code, whatever happens to the
> rest of the world.
>
> 3. I often compile releases on private clouds, which do not have access to
> internet. Yes, there are workarounds, but the point her is that it makes my
> life easier not to have to find one.
>
> Rebase 2 currently satisfies these requirements, and since I'd like to
> move to Rebase3 I'd like to find working alternatives.
>
> Eric, sure, I can host Hex privately. Though, you'll probably agree that
> it is way more easier to just go with the vendoring thing. :)
>
>
> That being said, I'd like for you, Tristan, Fred, Eric, to try and welcome
> my little feedback here, and take it for what it is. I'd like it to be easy
> and possible to discuss these ideas serenely, because relying on a system
> that considers (or better yet, values) the community input such as mine
> would make me sleep better at night :)
>
> All the best,
> r.
>
>

Just to add the discussion, "vendors" dependencies or at least a way to
have them in the source archive is a good way to ship the source code to
customers. Doing it remove any dependency to an external source that could
disappear or change over the time. It provides a final source product to
customers that can still be edited/modified in future without to worry
much. (they just need to make sure to archive correctly the deliverables).

I had a look at the vendor plugin and it's a good start. But I think
the "rebar3
vendor apply" should be automatic when you launch a build. Says if you have
a _vendor dir or something like it it would be used to deploy the deps
inside. Then we could have the following commands:

rebar3 vendor fetch
rebar3 vendor upgrade

What do you think about it? Can we right now hooks the way the dependency
is retrieved? Or do we need to provide some kind of custom dep resource [1]
that would proxy each deps? Seem like right now that _checkouts is an hack
and something like it can't be done externally. Anyway any hint is
appreciated. I also need to have such feature on a day basis :)

- benoit


[1] http://www.rebar3.org/docs/custom-dep-resources
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160319/9caa6ce1/attachment.htm>