It can be useful to build only bitcoind and still run the full test suite using an external bitcoin-cli instance.
Use case: Automated package testing can have a build-time dependency on the bitcoin-cli package and use it to run tests on a bitcoind-only build.
540 | 541 | - def is_cli_compiled(self): 542 | - """Checks whether bitcoin-cli was compiled.""" 543 | + def is_cli_available(self): 544 | + """Checks whether bitcoin-cli is available.""" 545 | + if os.getenv("BITCOINCLI", "__NOT_SET__") != "__NOT_SET__":
Why not just - if os.getenv("BITCOINCLI") != None:?
Python's documentation says getenv returns a string, but without a default it returns None in CPython. Providing a default avoids the ambiguity/contradiction.
In both Python 2 and 3 docs, default is None as well.
"key, default and the result are str."
But it actually returns None, which isn't string, if environment variable is not set, both in Python2 and Python3.
$ python
Python 3.6.5 (default, Sep 11 2018, 13:54:50)
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> type(os.getenv('unsetenvironmentvariable'))
<class 'NoneType'>
But that's not documented/guaranteed behaviour.
Default being None is documented.
Not as a return value.
I agree with @kristapsk here. The correct way to do this is:
if os.getenv("BITCOINCLI") is not None:
or, if you don't want to support an empty value / regard an empty value as unset
if not os.getenv("BITCOINCLI"):
Special-casing is a default value is, imo, fragile and ugly.
Special-casing the default here is well-defined, not fragile... the alternatives are what is fragile, since they're not guaranteed behaviours [yet?].
Returning None or a string is just the pythonic way to say it returns optional<string>
Returning None or a string is just the pythonic way to say it returns optional<string>
Exactly.
Concept ACK anyhow
Closing this and putting up for grabs, it's desirable functionality but not implemented in an acceptable way imo.