v0.6.2

[CagtayFabry]

Changes

prepare 0.6.2 release

create release PR

• create a PR that finalizes the code for the next version
  • name the PR according to the version vX.Y.Z and add the release
    tag (example here)
  • make sure CHANGELOG.rst is up to date and enter current date to the release version
  • add summarized release highlights where appropriate
  • update the CITATION.cff version number and date
  • search the project for deprecated and remove deprecated code
• wait for review and the CI jobs to finish
• check the readthedocs PR build

Merge the Pull Request

• merge normally and wait for all CI actions to finish on the main branch

add Git(hub) tag

• tag and release the current master version on GitHub using the Releases feature
  • name the release git tag according to the version released (e.g. v0.3.3)
  • name the GitHub release accordingly, omitting the v prefix (this can be change later so don't worry, in
    doubt use vX.Y.Z everywhere)
  • copy the changes/release notes of the current version into the description
    (this website can be used to convert rST -> MD)
• wait for all Github Actions to finish

ReadTheDocs update

• check the build processes for latest, stable and vX.Y.Z get triggered on RTD (the tag build can get
  triggered twice, resulting in a failed/duplicated build, no need to worry)

pypi release

• check the automatic release to pypi after the build action completes here

conda-forge release

• pypi release should get picked up by the conda-forge bot and create the new
  pull-request here
• carefully check the meta.yaml in the pull request, manually update all changes in the build and run dependencies
• merge with 2 or more approved reviews

[github-actions]

Test Results

2 184 tests  ±0   2 183 ✔️ ±0   2m 31s ⏱️ -32s
       1 suites ±0          1 💤 ±0 
       1 files   ±0          0 ❌ ±0 

Results for commit f13a0bc. ± Comparison against base commit cfac317.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

Merging #822 (f13a0bc) into master (e6f7d6a) will increase coverage by 0.44%.
The diff coverage is 99.12%.

@@            Coverage Diff             @@
##           master     #822      +/-   ##
==========================================
+ Coverage   96.80%   97.25%   +0.44%     
==========================================
  Files          81       82       +1     
  Lines        5380     4913     -467     
==========================================
- Hits         5208     4778     -430     
+ Misses        172      135      -37     

Impacted Files	Coverage Δ
weldx/geometry.py	96.61% <ø> (ø)
weldx/welding/groove/iso_9692_1.py	99.52% <ø> (ø)
weldx/core/math_expression.py	98.50% <98.50%> (ø)
weldx/core/spatial_series.py	100.00% <100.00%> (ø)
weldx/core/generic_series.py

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[CagtayFabry]

RTD nosedived into timeout from this build (working) to this one (timeout)

no idea why, here is the diff
https://github.com/BAMWelDX/weldx/pull/822/files/380909012841d5c898e0d3564b6a7d38390ee103..3535791f379354787732d151d594b71d0455a720

the conda installs seem identical (also with the github action run)... 🤔
https://github.com/BAMWelDX/weldx/actions/runs/3396067849/jobs/5646712658

[CagtayFabry]

I have removed the internal links in get_groove @marscher
I am not sure why the github action docs build is still failing, I cannot reproduce locally (it ran through in this action run)

I think this is ok for now

[marscher]

are there any performance implications for this change? This will trigger equality comparisons for set and dict operations.

I've seen deepsource complaining about this. But can't we redirect the hash function to XArray (if they offer one)?

[marscher]

Actually, mutable objects shouldn't be hashable at all. But there is a feature request for XArray to implement this any ways. pydata/xarray#4738

[CagtayFabry]

the way I see it this should have been the implicit behavior anyway (because we implement __eq__) but somehow deepsource didn't pick it up

[marscher]

I think if the equality operator is defined, and the hash method is just being derived, the object will still be hashable. So this is not just a cosmetic change to satisfy a linter.
Prior 0.6.2 this raised:

import weldx
x = weldx.core.MathematicalExpression("3*x")
gs = weldx.core.GenericSeries(x)
hash(gs)

TypeError: __hash__ method should return an integer