rebar3 dependencies

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rebar3 dependencies

Roberto Ostinelli-3
Dear list,
Does someone know if there's a way to vendor dependencies with rebar3, just like you do with ruby's bundler?

I always have the habit to commit dependencies too, and I've done so with rebar2 quite easily by committing the /deps folder too. However to my understanding with rebar3 all dependencies go into _build, which isn't supposed to be committed.

Any input welcome, I'm new to rebar3, am considering the switch but would like to tackle this first.

Thanks,
r.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
There is no built-in support for vendoring.

What is the use case? Is it for developers to be able to checkout a
single repo and begin working on the project without anything additional
needing to be fetched?

--
  Tristan Sloughter
  [hidden email]

On Fri, Mar 18, 2016, at 05:40 PM, Roberto Ostinelli wrote:

> Dear list,
> Does someone know if there's a way to vendor dependencies with rebar3,
> just like you do with ruby's bundler?
>
> I always have the habit to commit dependencies too, and I've done so with
> rebar2 quite easily by committing the /deps folder too. However to my
> understanding with rebar3 all dependencies go into _build, which isn't
> supposed to be committed.
>
> Any input welcome, I'm new to rebar3, am considering the switch but would
> like to tackle this first.
>
> Thanks,
> r.
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Michael Truog
On 03/18/2016 04:22 PM, Tristan Sloughter wrote:
There is no built-in support for vendoring. 

What is the use case? Is it for developers to be able to checkout a
single repo and begin working on the project without anything additional
needing to be fetched?

This use-case of rebar is an important one due to Erlang's focus
on fault-tolerance.  To make sure your built is robust and stable, it
requires having all your dependencies at a known state.  I understand
the lock file is a method to rely on remote repositories at a specific
commit and the commit should change if the repositories history is
rewritten.  However, repositories can disappear or be inaccessible
(in a deployment environment), and it is more dependable to have the
dependency stored along with the dependent source code
(to avoid a reliance on the remote repository, due to its potential
to fail in unexpected ways).

For pursuing fault-tolerance (seriously) this should be a way of using
rebar that is required functionality.

I have setup rebar2 to do this in https://github.com/CloudI/CloudI
but this is one area that prevents me from adopting rebar3 unless this
is easily done with using '
{project_app_dirs, ["external", "lib"]}'
instead of '
lib_dirs' ('lib_dirs' works with rebar2), or some other
method.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
This use-case of rebar is an important one due to Erlang's focus on fault-tolerance.  To make sure your built is robust and stable, it requires having all your dependencies at a known state.
 
Your build artifact for deployment is a release which does "bundle" all dependencies at a certain point in time.
 
For reproducibility in the event of losing the original release is, as you mention, what the lock files are for. When hex gains easy mirroring there will also be a quick way to ensure you have your own backups of alls your dependencies.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Michael Truog
On 03/18/2016 05:32 PM, Tristan Sloughter wrote:
This use-case of rebar is an important one due to Erlang's focus on fault-tolerance.  To make sure your built is robust and stable, it requires having all your dependencies at a known state.
 
Your build artifact for deployment is a release which does "bundle" all dependencies at a certain point in time.
 
For reproducibility in the event of losing the original release is, as you mention, what the lock files are for. When hex gains easy mirroring there will also be a quick way to ensure you have your own backups of alls your dependencies.
Yes, what I am talking about is having all the source code dependencies at a known state.
hex attempts to do this, but as you mentioned, is unable to be hosted privately and the public
hex site may go down at anytime for any length of time.

You appear to be avoiding the topic of putting all the source code dependencies into a
single repository and having them work with rebar3.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
That said, there are custom resources and plugins which make it possible to create a sort of "bundler" I'm sure http://www.rebar3.org/docs/custom-dep-resources
 
--
Tristan Sloughter
 
 
 
On Fri, Mar 18, 2016, at 07:58 PM, Tristan Sloughter wrote:
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.
_______________________________________________
erlang-questions mailing list
 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Michael Truog
In reply to this post by Tristan Sloughter-4
On 03/18/2016 05:58 PM, Tristan Sloughter wrote:
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.

While your opinion is that the approach is "bad", I see it as required for
stable and repeatable builds.  So we reach an impasse where it appears that
rebar3 is not meant to support this, unless by chance without it
intentionally being a use-case, which is unfortunate.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Eric Meadows-Jönsson
Yes, what I am talking about is having all the source code dependencies at a known state.
hex attempts to do this, but as you mentioned, is unable to be hosted privately and the public
hex site may go down at anytime for any length of time.

You can host Hex privately, there is nothing prohibiting you from hosting your own Hex repo or mirroring Hex.pm. 

On Sat, Mar 19, 2016 at 2:37 AM, Michael Truog <[hidden email]> wrote:
On 03/18/2016 05:58 PM, Tristan Sloughter wrote:
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.

While your opinion is that the approach is "bad", I see it as required for
stable and repeatable builds.  So we reach an impasse where it appears that
rebar3 is not meant to support this, unless by chance without it
intentionally being a use-case, which is unfortunate.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




--
Eric Meadows-Jönsson

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Michael Truog
On 03/18/2016 07:03 PM, Eric Meadows-Jönsson wrote:
Yes, what I am talking about is having all the source code dependencies at a known state.
hex attempts to do this, but as you mentioned, is unable to be hosted privately and the public
hex site may go down at anytime for any length of time.

You can host Hex privately, there is nothing prohibiting you from hosting your own Hex repo or mirroring Hex.pm.

While this may be possible, it is undocumented functionality, so it doesn't exist in a useable way.
The same was true of sinan/faxien in the past.


On Sat, Mar 19, 2016 at 2:37 AM, Michael Truog <[hidden email]> wrote:
On 03/18/2016 05:58 PM, Tristan Sloughter wrote:
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.

While your opinion is that the approach is "bad", I see it as required for
stable and repeatable builds.  So we reach an impasse where it appears that
rebar3 is not meant to support this, unless by chance without it
intentionally being a use-case, which is unfortunate.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




--
Eric Meadows-Jönsson


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Fred Hebert-2
In reply to this post by Michael Truog
On 03/18, Michael Truog wrote:
>
>While your opinion is that the approach is "bad", I see it as required for
>stable and repeatable builds.  So we reach an impasse where it appears that
>rebar3 is not meant to support this, unless by chance without it
>intentionally being a use-case, which is unfortunate.

Just so I'm clear, the feature you're after here is that rebar3 should
be able to fetch your dependencies and build them, but you just want
them to be fetched and built in a different location so that you do not
have to go fetch them yourself?

Because you could just go and place them yourself in libs/ (and put your
own in apps/, or else use {project_app_dirs, ["deps/*", "apps/*",
"lib/*", "."]} to have a deps/ directory) and then check this in.

This would split your code from where they are built, and would tell
rebar3 "don't handle these, I'll do it myself", which I assume is kind
of the point here, isn't it?

So the only thing missing there is fetching and upgrading, although is
this still a thing you want since you don't necessarily control the
order it is done in? Is this the thing not being handled that would be
critical?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
Putting them under project_app_dirs is a bad idea. It'll mean running
tests for the project will run all those tests, breaks the ability to
use it as a dependency of another apps, you can't have the same app in
the rebar.config and expect it to know the project_app of the same name
is the actual dep, etc...

To correctly do this a plugin should be created.

--
  Tristan Sloughter
  [hidden email]

On Fri, Mar 18, 2016, at 09:43 PM, Fred Hebert wrote:

> On 03/18, Michael Truog wrote:
> >
> >While your opinion is that the approach is "bad", I see it as required for
> >stable and repeatable builds.  So we reach an impasse where it appears that
> >rebar3 is not meant to support this, unless by chance without it
> >intentionally being a use-case, which is unfortunate.
>
> Just so I'm clear, the feature you're after here is that rebar3 should
> be able to fetch your dependencies and build them, but you just want
> them to be fetched and built in a different location so that you do not
> have to go fetch them yourself?
>
> Because you could just go and place them yourself in libs/ (and put your
> own in apps/, or else use {project_app_dirs, ["deps/*", "apps/*",
> "lib/*", "."]} to have a deps/ directory) and then check this in.
>
> This would split your code from where they are built, and would tell
> rebar3 "don't handle these, I'll do it myself", which I assume is kind
> of the point here, isn't it?
>
> So the only thing missing there is fetching and upgrading, although is
> this still a thing you want since you don't necessarily control the
> order it is done in? Is this the thing not being handled that would be
> critical?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Fred Hebert-2
On 03/18, Geoff Cant wrote:
>Wouldn't checkouts work for this case?
>

Yes and no. _checkouts work fine for local development, but it still
carries that pesky ebin/.

Tristan and I are discussing plugins for this. You could really have
`rebar3 vendor store' which copies from `_build/<profile>/lib' to
`deps/'  (minus the ebins), and `rebar3 vendor apply' which moves them
back to `_build/<profile>/lib'.

The plugin would only need to copy/move files around, and could still
use the rest of all rebar3's providers, without having us maintain it in
core.

That way you can experiment with upgrades, blowing stuff up, crushing
it, and so on, and still vendor your stuff in.

There's simple solutions for it, and we're hoping people can use the
plugin interface for that.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Tristan Sloughter-4
Yea, don't use _checkouts, that should be for local development and
removes the checkout app from the lock file.

People can try this https://github.com/tsloughter/rebar3_vendor

It has issues if you have git deps... but I think it is a start for
those who need this. Hopefully those who need it can improve it from
here :)

--
  Tristan Sloughter
  [hidden email]

On Fri, Mar 18, 2016, at 10:14 PM, Fred Hebert wrote:

> On 03/18, Geoff Cant wrote:
> >Wouldn't checkouts work for this case?
> >
>
> Yes and no. _checkouts work fine for local development, but it still
> carries that pesky ebin/.
>
> Tristan and I are discussing plugins for this. You could really have
> `rebar3 vendor store' which copies from `_build/<profile>/lib' to
> `deps/'  (minus the ebins), and `rebar3 vendor apply' which moves them
> back to `_build/<profile>/lib'.
>
> The plugin would only need to copy/move files around, and could still
> use the rest of all rebar3's providers, without having us maintain it in
> core.
>
> That way you can experiment with upgrades, blowing stuff up, crushing
> it, and so on, and still vendor your stuff in.
>
> There's simple solutions for it, and we're hoping people can use the
> plugin interface for that.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Michael Truog
On 03/18/2016 08:35 PM, Tristan Sloughter wrote:
> Yea, don't use _checkouts, that should be for local development and
> removes the checkout app from the lock file.
>
> People can try this https://github.com/tsloughter/rebar3_vendor
>
> It has issues if you have git deps... but I think it is a start for
> those who need this. Hopefully those who need it can improve it from
> here :)
>
Thank you for providing the start of a plugin for this.
I will use this when doing a conversion to rebar3 and may have
changes if any are required.

Thanks,
Michael
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Alin Popa
In reply to this post by Eric Meadows-Jönsson
On 19 Mar 2016, at 02:03, Eric Meadows-Jönsson <[hidden email]> wrote:

Yes, what I am talking about is having all the source code dependencies at a known state.
hex attempts to do this, but as you mentioned, is unable to be hosted privately and the public
hex site may go down at anytime for any length of time.

You can host Hex privately, there is nothing prohibiting you from hosting your own Hex repo or mirroring Hex.pm. 

Could you please give us more details on how to do this, or even some unofficial/yet to be released documentation?

Thanks,
Alin

On Sat, Mar 19, 2016 at 2:37 AM, Michael Truog <[hidden email]> wrote:
On 03/18/2016 05:58 PM, Tristan Sloughter wrote:
You appear to be avoiding the topic of putting all the source code dependencies into a single repository and having them work with rebar3.
 
I think it is unnecessary and poor form. Especially if you application is public and others want to depend on it.

While your opinion is that the approach is "bad", I see it as required for
stable and repeatable builds.  So we reach an impasse where it appears that
rebar3 is not meant to support this, unless by chance without it
intentionally being a use-case, which is unfortunate.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




--
Eric Meadows-Jönsson
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Roberto Ostinelli
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.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Benoit Chesneau-2


On Sat, Mar 19, 2016 at 8:30 AM Roberto Ostinelli <[hidden email]> 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




 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Eric Meadows-Jönsson
While this may be possible, it is undocumented functionality, so it doesn't exist in a useable way.
The same was true of sinan/faxien in the past.

But it's not undocumented. In fact everything that makes up Hex is specified and documented. Hex.pm is simply an implementation of those specifications. 

 Could you please give us more details on how to do this, or even some unofficial/yet to be released documentation?

Here you have all the specifications for Hex https://github.com/hexpm/specifications. To run your own repository or hex.pm mirror you simply have to implement the repository endpoints https://github.com/hexpm/specifications/blob/master/endpoints.md#repository. If you find anything that is not documented it's a bug.

On Sat, Mar 19, 2016 at 9:57 AM, Benoit Chesneau <[hidden email]> wrote:


On Sat, Mar 19, 2016 at 8:30 AM Roberto Ostinelli <[hidden email]> 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




 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




--
Eric Meadows-Jönsson

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: rebar3 dependencies

Fred Hebert-2
In reply to this post by Roberto Ostinelli
On 03/19, Roberto Ostinelli wrote:
>Tristan, Fred, Eric
>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 :)
>

We do, Tristan even started a toy plugin here for you :)

It would certainly have been easier for us if these concerns had been
brought to us in the last year and a half we have spent in beta, alpha
and pre-alpha, though, rather than week 1 after stable release.

It's now too late to change the core, so we must think in plugins.  
Hopefully what we can come up with will prove satisfactory.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12