add NO_OP mode to rustup-init.sh

[onur-ozkan]

As part of one of my tasks I need to resolve the target triple at the shell script level during the initial bootstrap phase (before rustc is available). The functionality is already implemented in the rustup script and I don't want to duplicate it in the upstream rust repository. My plan is to fetch the rustup script from https://sh.rustup.rs using curl and then source it from the caller script, so I can access/execute the get_architecture function. However, this is not possible because it immediately initiates the download process. As a solution to that, I propose this PR (which is a dead-simple change) that allows us to source this file easily (like NO_OP=1 . ./rustup-init.sh) without runnig the actual workflow.

[djc]

As part of one of my tasks I need to resolve the target triple at the shell script level during the initial bootstrap phase (before rustc is available).

What are you actually trying to achieve?

I'm not inclined to add complexity to this script in order to support niche use cases like this. You can just copy the source code of the rustup-init.sh.

[onur-ozkan]

fwiw initially I tried adding "--no-op/-n" argument, but passing arguments wasn't working well when sourcing the script file.

[onur-ozkan]

What are you actually trying to achieve?

We are replacing the python sources from bootstrap with shell scripts in order to remove python dependency on bootstrap. Which means we need to figure out the target triple and download its stage0 artifacts.

I'm not inclined to add complexity to this script in order to support niche use cases like this. You can just copy the source code of the rustup-init.sh.

The change is quite simple actually. Do you think copying part of this source will be better in terms of maintainability? It seems much complex solution IMO.

[rami3l]

As part of one of my tasks I need to resolve the target triple at the shell script level during the initial bootstrap phase (before rustc is available).

What are you actually trying to achieve?

I'm not inclined to add complexity to this script in order to support niche use cases like this. You can just copy the source code of the rustup-init.sh.

@djc I think the goal is to reuse Rustup's host triple resolution as a shell script module.

@onur-ozkan I guess rustup-init.sh it's not intended to be imported, so it is not guaranteed to have a stable API surface... OTOH I can see how it might be helpful to reuse a part of its logic. How about duplicating the functionalities you need in another repo first? I guess we can figure out how to reuse it later (e.g. submodules is an option).

[onur-ozkan]

@djc I think the goal is to reuse Rustup's host triple resolution as a shell script module.

Correct.

@onur-ozkan I guess rustup-init.sh it's not intended to be imported, so it is not guaranteed to have a stable API surface... OTOH I can see how it might be helpful to reuse a part of its logic. How about duplicating the functionalities you need in another repo first? I guess we can figure out how to reuse it later (e.g. submodules is an option).

I can duplicate the script, I thought it would be much better to import the script right away (as the change we are adding here simply quits the process, it should be stable enough) so we don't have to maintain/sync the another copy. But I see your point, I can copy it as a start.

[rami3l]

I can duplicate the script, I thought it would be much better to import the script right away (as the change we are adding here simply quits the process, it should be stable enough) so we don't have to maintain/sync the another copy. But I see your point, I can copy it as a start.

@onur-ozkan I mean I don't see why we cannot both depend on some same thing in the end. If you have found out the right boundaries to make the split, we can depend on you instead :)

PS: This functionality is especially interesting for our downstreams as well. PPS: Please note that the logic of get_architecture() is going through a change in #3800.