shesek
commented
3 years ago AFAICT this example is actually the only place where a version number is hardcoded, in other places it uses the configurable {BITCOIND,BWT,BTCEXP,SPECTER}_{VERSION,SHA256} environment variables or the latest version available via apt.
rebuilding this image with different+newer debian based base, like debian:sid-slim or ubuntu:rolling will require changing it to newer version
Generally speaking, making it possible to seamlessly switch base images is not a design goal for eznode -- it's likely that other things will break too and require some code changes, so having to also change the version number isn't terrible.
For now, I changed the invocation to use python3 in 411df23f12ce2c1de075f5ab280c4cf15f888969, but kept the installation hardcoded to 3.7.
I'm closing the issue for now, but I'm gonna refactor this a bunch at some point, and might re-think this then. (Currently python/nodejs are installed directly by the packages that require them (specter/btc-rpc-explorer), which isn't great and would result in duplication when more packages that use them are added.)
For example the script use
python3.7in several places: https://github.com/ez-org/eznode/blob/08e914c29b2a96ec78fb2930c1b7c91a9b178ffc/specter/run#L45 https://github.com/ez-org/eznode/blob/9600579fb0cc16103c2183f4827aef6dd403b012/specter/install#L12-L13 etc.. rebuilding this image with different+newer debian based base, likedebian:sid-slimorubuntu:rollingwill require changing it to newer version (in debian 11 it'spython3.9), thus using a variable for the version when it's part of the package-name is better (replace in 1 place to upgrade)also it's recommended to rebuild the image with testing using above testing/cutting-edge bases, to uncover issues, stuff to fix, etc..