Adopt to changed lightningd api about lightning-charge HOT 4 OPEN

The new subdirectory structure simply means that the user has to specify the subdirectory as part of the --ln-path argument.

How would you adopt to improve this?

(Note that Lightning Charge does not even have a --network argument, it only accepts the path to the directory, so it couldn't know which network to expect. The NETWORK env var that charge does have is only used in the docker deployment for setting automatically up lightningd/bitcoind.)

from lightning-charge.

wouldn't it be a solution to extend charged api to have a --network argument. The solution with passing the path was what I explained to the person with the issue on stack exchange. But maybe you are right and everything right now is well. I just thought it might be confusing for more people than the initiater of the stack exchange topic

from lightning-charge.

Lightning Charge does default to using mainnet if it seems like the user provided the parent data directory instead of the network-specific one (while also showing a deprecation message for this usage). Wouldn't that solve it for most people?

from lightning-charge.

The problem was that the user used an old docker image in which the lightning node did not make a difference about which network was used as there were not subdirectories. while the user realized that there was a problem with the directory path the user did not understand the subdirectory structure. I thought such an API change might confuse others who might not bother to ask a question thus I pointed it out here. I was just wandering if there is something on charged side that could be done to improve the user experience.
I remembered that my first experience with bitcoin / lightning was actually after charge was released. I had no ideas that the software talks through an RPC interface and at that time I would have been overwhelmed by such error messages and probably frustrated decided to move on.

from lightning-charge.