Issues found during manual testing of 0.8.0 at deRSE24

softwarepub / hermes

Implementation of the HERMES workflow

https://docs.software-metadata.pub

Other

21 stars 6 forks source link

Issues found during manual testing of 0.8.0 at deRSE24 #244

Open poikilotherm opened 8 months ago

poikilotherm commented 8 months ago

[x] No log output?
[x] No complaints about invalid CFF file -> Logs are not enabled by default, missing init to ERR/WARN/INFO.
[x] No complaints about non-existent or missing configuration options (example: harvest.cff.validate -> harvest.cff.enable_validation & harvest.from -> harvest.sources renamed) (Potential duplication of above)
[x] #259
[x] #260

poikilotherm commented 8 months ago

Version given as 1.0 in CFF is interpreted as floating point (YAML parser!) and will give an error at deposit because not a valid string. We need to do a hard cast to string for the version

led02 commented 3 months ago

Logs and errors are now handled a bit saner... i.e., the errors are output to the log.error channel (which is by default printed on the console).

Still lot's of stuff to do that will be handled in different issues (i.e., #238).

sdruskat commented 2 months ago

During the workshop, it was also mentioned that hermes should support older Python versions (i.e., 3.8).

I'm strictly against this, seeing that EOLs are approaching fast. 3.8 will be unsupported from October 2024, 3.9 October 2025.

I'd argue that requiring 3.10 is actually feasible and shouldn't be changed.

I.e., whoever is working on the 3.8 backport (mentioned in the paper draft) should drop their pen IMHO.

led02 commented 2 months ago

I think 3.8 was also required to support SOMESY

sdruskat commented 2 months ago

I think 3.8 was also required to support SOMESY

True. I suggest asking somesy to update to 3.10 instead of supporting versions near the EOL. Or were there any (dependency-related) reasons for sticking with 3.8 (other than: a lot of people still use it)?