Ensure update_sp.py is executable from any directory not just docs/

[network-charles]

The script was initially only able to run when executed from the docs/ directory. Hence, the error @rkratky was experiencing in this issue #420.

SPHINX_DIR = os.path.join(os.getcwd(), ".sphinx")

os.getcwd() retrieves the current working directory and joins .sphinx to it. This makes it only executable from the docs/ directory. A more efficient way is to make it executable from any directory.

So, I opted to use os.path.dirname(__file__) to retrieve the file path to the update_sp.py script. os.path.abspath ensures that the path joined later in the script uses the full directory from root, where the script is stored locally.

[rkratky]

Thanks, @network-charles. While you're at it, could you please consider also fixing the new_requirements code, so that it doesn't assume the script is executed from the docs/ directory? At this point, it only checks for the requirements.txt file with this:

with open("requirements.txt", "r") as file:

which fails when run from anywhere but docs/.

[rkratky]

Aaand, another similar thing with the NEWFILES.txt file, which is currently written with:

with open("NEWFILES.txt", "w") as f:

so it ends up in the directory from which the script is run. I.e. it can end up anywhere, which is not desirable.

[network-charles]

Aaand, another similar thing with the NEWFILES.txt file, which is currently written with:

with open("NEWFILES.txt", "w") as f:

so it ends up in the directory from which the script is run. I.e. it can end up anywhere, which is not desirable.

Alright

[network-charles]

Troubleshooting this script isn't intuitive because the logging levels aren't properly used. I found it challenging to distinguish between the script's actions and the outputs it generates.

I had this issue when outputting the item variable at Line 141.

In an old PR, one of the maintainers said, Using a print "... is intended to provide specific information on what the script is doing. Logging is to debug issues." However, this statement isn't entirely accurate. Logging works beyond debugging issues.

There are parts where a banner-like warning is outputted, for example, at Lines 153-157. It would have made more sense to use a one-line warning log level there and not just several print outputs. So, while troubleshooting, you know that this is a log-related warning and not just a banner. Sometimes, if you aren't careful, you might have assumed the banner was outputted from what you are troubleshooting.

I don't want to address this issue immediately in this PR because I want to solve the current issue. However, this will be great to address in a new PR.

[rkratky]

this will be great to address in a new PR

Thanks. I'd suggest filing an issue about it first, so that if ppl have opinions, it can be resolved before a PR is submitted.

[network-charles]

Alright