[erlang-questions] 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 <bchesneau@REDACTED>
wrote:

>
>
> 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
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Eric Meadows-Jönsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160319/7e28d462/attachment.htm>