Skip to content
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

rebar3 version compiles dependencies before outputting value #2865

Closed
paulo-ferraz-oliveira opened this issue Feb 22, 2024 · 5 comments
Closed

Comments

@paulo-ferraz-oliveira
Copy link
Contributor

Pre-Check

  • I found no current issues for this (quick search)
  • I'm willing and interested in helping fix the issue

Environment

  • rebar3 3.22.1

Current behaviour

My use case is as follows:

  • I want to use erlef/setup-beam's version-file (e.g. .tool-versions) build option
  • for that I need to use actions/checkout before I use erlef/setup-beam (because my .tool-versions is checked in to my project - for CI/local sync. purposes)
  • when I do use erlef/setup-beam the action attempts to output the chosen rebar3 version, for debugging purposes, via rebar3 version
  • this forces a compilation of my project that will e.g. fail in a step it shouldn't (because I wasn't expecting it to be compiled for this reason: rebar3 version)

My question is: is it absolutely necessary that rebar3 version attempts compilation?

Expected behaviour

No compilation should be required for rebar3 version.

@ferd
Copy link
Collaborator

ferd commented Feb 22, 2024

rebar3 version has no command dependencies and does not require compiling before outputting a version.

An exception can be made for this specifically for global plugins if they are defined in a global configuration file, because a global project plugin could override the version command and must therefore be evaluated before any command is run. To avoid that, calling it with a path such as REBAR_GLOBAL_CONFIG_DIR=/fake-dir rebar3 version will necessarily bypass any such checks and output faster.

@ferd
Copy link
Collaborator

ferd commented Feb 22, 2024

Now that I think about it, calling rebar3 version from within a project that defines plugins will also have the same effect. REBAR_GLOBAL_CONFIG_DIR=/fake-dir REBAR_CONFIG=fake.config rebar3 version should cancel out all config file reading if you can't call the version from a neutral location.

@paulo-ferraz-oliveira
Copy link
Contributor Author

Oh, cool. I can live with REBAR_GLOBAL_CONFIG_DIR=/fake-dir REBAR_CONFIG=fake.config. My use case is basically setup-beam which affects many consumers. Thanks, @ferd.

paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
@ferd
Copy link
Collaborator

ferd commented Feb 22, 2024

If I recall correctly you can also grab the version from the top of the escript, but it won't be as complete:

$ head -2 rebar3 | tail -1
%% Rebar3 3.22.1

The full version gives specific hashes with the OTP version and is more useful.

paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
@paulo-ferraz-oliveira
Copy link
Contributor Author

Cool, thanks. At the moment I'm running it, though, making sure it's executable, and in the path, is also part of the test 😄

paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
paulo-ferraz-oliveira added a commit to erlef/setup-beam that referenced this issue Feb 22, 2024
What are we fixing?

If you're with'ing "version-file": ".tool-versions" after you
_use_ "actions/checkout", it's likely `rebar3` from `setup-beam`
is compiling your project just to output its
version

This commit prevents that as per
erlang/rebar3#2865 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants