Use stellar binary instead of soroban binary

[juliankuners]

On May 9, 2025, the pull request stellar/stellar-cli#2024 removed the soroban binary from the stellar-cli crate. As the CI docker container installs the up-to-date version of the stellar-cli crate, integration tests fail due to the missing soroban binary. This currently blocks pull requests due to failing CI.

This pull request fixes this issue by replacing usage of the soroban binary with the stellar binary.

[juliankuners]

I ran into a problem using komet, as the stellar binary, and previously soroban binary, are not provided in the PATH of the wrapped komet binary. Therefore, komet fails if stellar, and previously soroban, are not installed in the system PATH. I'll push a commit to fix this and then re-open this pull request. Please note that this issue also existed prior to this pull request.

[bbyalcinkaya]

I ran into a problem using komet, as the stellar binary, and previously soroban binary, are not provided in the PATH of the wrapped komet binary. Therefore, komet fails if stellar, and previously soroban, are not installed in the system PATH. I'll push a commit to fix this and then re-open this pull request. Please note that this issue also existed prior to this pull request.

@juliankuners
Thanks for pointing this out! Just to clarify, this was an intentional decision. We discussed it internally early on and chose not to include the Soroban CLI in the Komet package installed via kup. As a result, after installing Komet via kup, users are expected to install the soroban CLI separately and ensure it’s available in their PATH.

The changes in this PR look good as is. I can approve it.

[juliankuners]

I ran into a problem using komet, as the stellar binary, and previously soroban binary, are not provided in the PATH of the wrapped komet binary. Therefore, komet fails if stellar, and previously soroban, are not installed in the system PATH. I'll push a commit to fix this and then re-open this pull request. Please note that this issue also existed prior to this pull request.

@juliankuners Thanks for pointing this out! Just to clarify, this was an intentional decision. We discussed it internally early on and chose not to include the Soroban CLI in the Komet package installed via kup. As a result, after installing Komet via kup, users are expected to install the soroban CLI separately and ensure it’s available in their PATH.

The changes in this PR look good as is. I can approve it.

I see, that makes sense. In the nix flake file, there is leftover code to build stellar-cli that is not actually used. Nowadays, the stellar-cli repository provides a nix flake out-of-the-box: stellar/stellar-cli/flake.nix. I already made the necessary changes locally and it works as expected, with the exception that the stellar-cli derivation requires a fix for NixOS based systems due to some openssl build dependency impurity issue.

It is good practice to keep nix derivations pure, i.e., independent of the environment the program is running in. Is there any specific reason as to why it was decided to not ship the stellar/soroban binary with komet? Because otherwise, I'd like to ship my local changes in a new PR. This would also improve the out-of-the-box experience when installing komet with kup, as komet would always work as expected.

[juliankuners]

I ran into a problem using komet, as the stellar binary, and previously soroban binary, are not provided in the PATH of the wrapped komet binary. Therefore, komet fails if stellar, and previously soroban, are not installed in the system PATH. I'll push a commit to fix this and then re-open this pull request. Please note that this issue also existed prior to this pull request.

@juliankuners Thanks for pointing this out! Just to clarify, this was an intentional decision. We discussed it internally early on and chose not to include the Soroban CLI in the Komet package installed via kup. As a result, after installing Komet via kup, users are expected to install the soroban CLI separately and ensure it’s available in their PATH.
The changes in this PR look good as is. I can approve it.

I see, that makes sense. In the nix flake file, there is leftover code to build stellar-cli that is not actually used. Nowadays, the stellar-cli repository provides a nix flake out-of-the-box: stellar/stellar-cli/flake.nix. I already made the necessary changes locally and it works as expected, with the exception that the stellar-cli derivation requires a fix for NixOS based systems due to some openssl build dependency impurity issue.

It is good practice to keep nix derivations pure, i.e., independent of the environment the program is running in. Is there any specific reason as to why it was decided to not ship the stellar/soroban binary with komet? Because otherwise, I'd like to ship my local changes in a new PR. This would also improve the out-of-the-box experience when installing komet with kup, as komet would always work as expected.

I created a new pull request: #84. The discussion can be moved to this new pull request.

This pull request on the other hand is ready for review and the problem it fixes blocks other pull request due to failing CI.