Release of 4.0.8

[dostuffthatmatters]

Integration still in progress:

• Freeze the poetry dependencies to the one used in 4.0.7
• Remove git commit SHA from emails
• Closes Unreachable Peer PLC issue since 4.0.7  #151
• Closes Improve astronomy utilities #126
• Closes Pass config to Astronomy directly instead of setting the class parameter in config-logs #125
• Closes Issue with Astropy with stations that don't have an internet connection #154
• Closes PLC Exception Timeout doesn't work when PLC is controlled by user #157
• Closes Reduce codebase size by using tum-esm-utils more #165
• Closes Eliminate possibility to start the Core from multiple PYRA versions at the same time #156
• Closes Some Helios cameras don't accept new settings #167
• Close Helios autoexposure is not properly working #169

[netlify]

✅ Deploy Preview for pyra-4-documentation ready!

Name	Link
🔨 Latest commit	dd29bae
🔍 Latest deploy log	https://app.netlify.com/sites/pyra-4-documentation/deploys/64898428e404990008e7add0
😎 Deploy Preview	https://deploy-preview-166--pyra-4-documentation.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[dostuffthatmatters]

@patrickjaigner do you want to have a look at it before we try to run it on system ma?

[dostuffthatmatters]

Had to rebase it onto the main branch, that is why I force-pushed.

[patrickjaigner]

Is this the best way to do this?

[dostuffthatmatters]

I think so.

run_pyra_core.py will acquire that lock before the mainloop starts and frees it when the program finishes or crashes:

pyra/run_pyra_core.py

Lines 14 to 22 in 52eb662

	if __name__ == "__main__":
	try:
	_run_pyra_core_lock.acquire()
	try:
	main.run()
	finally:
	_run_pyra_core_lock.release()
	except filelock.Timeout:
	print("Aborting start: core process is already running")

When the pyra-cli start command cannot acquire the Lock, some Pyra Core process must be running.

The other option would be to cycle through all running processes (like the is-running command), but I think that is more work to implement because there are different cases.

[patrickjaigner]

Why could you remove this line?

[dostuffthatmatters]

I could remove this because the new Astronomy class implementation will throw an exception when the current sun elevation is not a float. I return float(output from skyfield library):

pyra/packages/core/utils/astronomy.py

Lines 60 to 69 in 52eb662

	current_position = earth + skyfield.api.wgs84.latlon(
	latitude_degrees=lat,
	longitude_degrees=lon,
	elevation_m=alt,
	)
	sun_pos = current_position.at(current_time).observe(sun).apparent()
	altitude, _, _ = sun_pos.altaz()
	return float(altitude.degrees)

[dostuffthatmatters]

There is also a new test that draw random datetimes from each year between 2020 and 2050 and checks if the Astronomy class can generate an elevation for that: https://github.com/tum-esm/pyra/blob/integration-4.0.8/tests/utils/test_astronomy.py

[patrickjaigner]

Could you let me know why you changed the Docstrings? Now they are different lengths and also every shorter than the rest of the code.

[dostuffthatmatters]

Sure! The wide comment blocks are hard to read on small monitors. I often work with two files open next to each other:

But when the lines of the doc strings are very long, it is super annoying when every lines wraps to a new line:

On big monitors, that is not an issue but whenever using two files or doing any diffing stuff on a tiny one, it bothers a lot.

Would you like to revert it?

[patrickjaigner]

Didn't realize this, but sure let's keep the changes.

[patrickjaigner]

I think we should not keep in in the code, but move it to the issue.

[patrickjaigner]

I finished reading through the changes. There is a lot of good refactoring done. I also added some comments for lines where I needed clarification on why changes were made.

Overall we should think about how easy and accessible the tum-esm-utils library is. Will people easily find the API description (a quick Google search didn't give me the correct result) or will it confuse people as relevant code is now moved to a different repository? I'm unsure if I like it for Pyra, as it will make it harder for people to add additional things to functions or make changes. What do you think?

[dostuffthatmatters]

I finished reading through the changes. There is a lot of good refactoring done. I also added some comments for lines where I needed clarification on why changes were made.

Thank you for the review 👍

Overall we should think about how easy and accessible the tum-esm-utils library is. Will people easily find the API description (a quick Google search didn't give me the correct result) or will it confuse people as relevant code is now moved to a different repository? I'm unsure if I like it for Pyra, as it will make it harder for people to add additional things to functions or make changes. What do you think?

Good question! The index of DuckDuckGo is great:

But the index of Google is terrible 😅:

(Both searches were done on a browser with no local traces of me)

You are right about making changes harder by outsourcing thinks. Three things I would do:

• We can add a link to the utils repository to every project's README that uses it, this way, the page rank will improve and Google should have it soon too.

• If we adhere to only outsource the things that are very general (run_shell_command, merge_dicts) and strictly type and document all functions, I think this is an improvement on the complexity of all projects that use the library. The current set of functions is already well documented I think, and most custom utility folder has worse testing and documentation than this library:
  

• We can add a link to the repository, the website and the PyPI page to the doc string of the module, then it is quicker to find documentation about it:
  

[dostuffthatmatters]

EDIT: Regarding the documentation of the utility library, from 1.5.2 (https://pypi.org/project/tum-esm-utils/1.5.2/), the module doc strings will include more information:

demo.mp4

[patrickjaigner]

@dostuffthatmatters Finished my review. All points clarified, thank you.

[dostuffthatmatters]

@patrickjaigner this is running well on the integration station. Do you approve the release?

[patrickjaigner]

@dostuffthatmatters Sounds good. Let's confirm a 7 days stable run of the release. Other than that I agree that 4.0.8 is ready to go.