-
Notifications
You must be signed in to change notification settings - Fork 520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bare compiler should not require a hex registry #958
Comments
Would there be a problem to having the compiler fetch its own registry? The problem is possibly (as you pointed out on IRC) with plugins required in order to properly compile. In such cases, unless the user of the bare compiler were to fetch plugins and compile them on rebar3's behalf then somehow passed in the proper path, I don't think we could avoid the registry being there. |
If the compiler automatically fetches the registry or if mix can pass the path of its own registry to rebar works for me. |
Another option would be for mix to treat plugins as normal dependencies so we fetch. In this case they should be available when rebar runs and fetching the registry would not be necessary for rebar. I will try this out and let you know how it works out. |
This also is relevant to making rebar3 useful for building stuff in hermetic environment (e.g. Debian effort to make packages reproducible and Nix/NixOS build processes). Currently I need to work around this by manually providing registry file, as seen here: This registry is not really needed, since all dependencies of built project are already provided locally and, I believe, rebar has enough information from rebar.config to validate that deps are the same as requested. |
Ping? |
Pong. not really sure what to do here. |
Currently rebar3 combines two things in one:
I believe Eric means to not do any of (2) if everything mentioned in config files is available locally to be compiled. |
With the bare compiler rebar assumes that the user have provided all dependencies and that they are correct so rebar should not need the registry to proceed. |
Ah. hm. I suppose doing plugin install in But plugins then won't be installed or used which isn't right either, and I don' tknow how to resolve that. |
If possible the way I would like plugins to be handled would be that I make sure the plugins rebar need are available in the code path the same way I do for dependencies. Would that make sense? |
The problem there is rebar3 treats plugins differently from deps so it doesn't accept a dep as a plugin. As in, if you have a dep A at vsn X you may have a plugin that also has dep A but at vsn Y. So plugins are installed to |
That is unless you pass a |
If rebar handles plugins separately from deps there is no reason for mix to handle them because as far as I can tell they will never conflict with mix deps. So we can close this issue for my part. Could we tell rebar where the registry is located so we don't have to make multiple requests to fetch it? Keep in mind that mix may call rebar multiple times to compile dependencies. |
We don't use the original registry for package look up :(. It gets converted to a |
@tsloughter That would be perfectly fine. |
@ericmj is this still required? Trying to filter issues. |
It's not implemented yet afaik but it's also not a hard requirement. It On Tuesday, 7 June 2016, Fred Hebert notifications@github.com wrote:
Eric Meadows-Jönsson |
Similarly to PATH env variable, this allows to pass paths to bare compiler which do not fit nicely into a single wildcard structure. Colon (":") is used as separator. This provides more flexibility when rebar is run in offline/hermetic environment, e.g. erlang#958 and erlang#1281.
Similarly to PATH env variable, this allows to pass paths to bare compiler which do not fit nicely into a single wildcard structure. Colon (":") is used as separator. This provides more flexibility when rebar is run in offline/hermetic environment, e.g. erlang#958 and erlang#1281.
Similarly to PATH env variable, this allows to pass paths to bare compiler which do not fit nicely into a single wildcard structure. Colon (":") is used as separator. This provides more flexibility when rebar is run in offline/hermetic environment, e.g. erlang#958 and erlang#1281.
Is this still the case? |
I think there was a way to do it with only the local registry, at least since we shipped the v2 of the hex API, since we now work from a partial index rather than a complete one. |
It complains until I run
rebar3 update
and then works.The text was updated successfully, but these errors were encountered: