style: cookiecutter and pre-commit formatting updates

[cadenmyers13]

Also updated copyright from 2024 to 2025. Did not add a news item because code functionality does not change.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.78%. Comparing base (1521c33) to head (9216a29).
Report is 13 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #77   +/-   ##
=======================================
  Coverage   93.78%   93.78%           
=======================================
  Files           4        4           
  Lines         177      177           
=======================================
  Hits          166      166           
  Misses         11       11           

Files with missing lines	Coverage Δ
tests/integration_test.py	98.03% <100.00%> (ø)
tests/test_fourigui.py	99.07% <100.00%> (ø)

[sbillinge]

Please see inline comments. For copyright statements, give them the correct range as best as you can figure it out. Code written by Sani was with when he was here which was around when he published his paper (a bit before)

[sbillinge]

Please see new way of handling news to her everything passing

[sbillinge]

Could of small things. Also, a bunch of the copyrights seen to have disappeared. Please check any file you edited is updated to <original date> - 2025

[cadenmyers13]

@bobleesj Can we add functionality to better handle copyright in scikit-package? Whenever the cookiecutter is ran, it overwrites the previous, accurate copyright which forces you to go back in and change things manually.

When we run scikit, we could add a user input response that says "Year of first release:". If its before the current year, then the copyright would update with a hyphen (ie. Copyright 2022-2025). If its a new package or was published within the current year, that could be the default response (ie. Copyright 2025). We would have to be thoughtful not to have unnecessary hyphens, but I think this would streamline things a bit. Thoughts?

[cadenmyers13]

Could of small things. Also, a bunch of the copyrights seen to have disappeared. Please check any file you edited is updated to <original date> - 2025

Okay, the copyrights should be good now. Let me know if things look off on your end.

[bobleesj]

Maybe. But I dont see a big benefit because one could simply run git diff and run git restore . This doesn't require that many files to review and we want users to do this actuall.

Second, some packages and within ours have likely have different license formats and we dont want to force non diffpy users to enter this year info

[sbillinge]

Maybe. But I dont see a big benefit because one could simply run git diff and run git restore . This doesn't require that many files to review and we want users to do this actuall.

Second, some packages and within ours have likely have different license formats and we dont want to force non diffpy users to enter this year info

Yes, this is correct. It is only relevant for the package update modality and then the file header info could be anything.

On the other hand, if we are using a standard file header in our package create, we could do an update that assumes this format and does nothing if there is no pattern match?