<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">While this may be possible, it is undocumented functionality, so it doesn't exist in a useable way.</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">The same was true of sinan/faxien in the past.</span></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-size:12.8px">Could you please give us more details on how to do this, or even some unofficial/yet to be released documentation?</span></blockquote><div><br></div><div>Here you have all the specifications for Hex <a href="https://github.com/hexpm/specifications">https://github.com/hexpm/specifications</a>. To run your own repository or <a href="http://hex.pm">hex.pm</a> mirror you simply have to implement the repository endpoints <a href="https://github.com/hexpm/specifications/blob/master/endpoints.md#repository">https://github.com/hexpm/specifications/blob/master/endpoints.md#repository</a>. If you find anything that is not documented it's a bug.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 19, 2016 at 9:57 AM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sat, Mar 19, 2016 at 8:30 AM Roberto Ostinelli <<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Tristan, Fred, Eric</div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rebase 2 currently satisfies these requirements, and since I'd like to move to Rebase3 I'd like to find working alternatives.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. :)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">All the best,</div><div class="gmail_extra">r.</div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div><br></div></div></div><div>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).</div><div><br></div><div>I had a look at the vendor plugin and it's a good start. But I think the "<span style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;line-height:inherit;color:rgb(51,51,51);background-color:transparent">rebar3 vendor apply" </span>should<span style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;line-height:inherit;color:rgb(51,51,51);background-color:transparent"> </span>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:</div><div><br></div><div>rebar3 vendor fetch</div><div>rebar3 vendor upgrade</div><div><br></div><div>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 :)</div><div><br></div><div>- benoit</div><div><br></div><div><br></div><div>[1] <a href="http://www.rebar3.org/docs/custom-dep-resources" target="_blank">http://www.rebar3.org/docs/custom-dep-resources</a></div><div><br></div><div><br></div><div> </div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Eric Meadows-Jönsson</div>
</div></div>