Skip to content

Complete the MEOS 1.3 bump (carries PR #72)#82

Open
estebanzimanyi wants to merge 19 commits into
masterfrom
bump/meos-1.3
Open

Complete the MEOS 1.3 bump (carries PR #72)#82
estebanzimanyi wants to merge 19 commits into
masterfrom
bump/meos-1.3

Conversation

@estebanzimanyi
Copy link
Copy Markdown
Member

Picks up the work in #72 (Diviloper) and closes the gaps that were keeping it from being mergeable: cherry-picks the missing master commit (Arijit Samal's distance_datespan_datespan fix), resolves the resulting conflict in pymeos/collections/time/datespan.py with the explicit DateSpan / DateSpanSet branches, fixes a circular import in pymeos/mixins (comparison + simplify) by moving the Temporal import under TYPE_CHECKING, and corrects a temporal_equal_1 typo in tfloat_test.py. Depends on the matching PyMEOS-CFFI #17 commit that adds the Datum helpers and the int *count auto-detect; with both branches in pytest reports 4472 / 4482 with only 10 pre-existing fixture mismatches outstanding. Once this lands, the 1.4 bump (PR #81) rebases cleanly on top.

Diviloper and others added 12 commits December 1, 2024 19:02
…oint to TGeomPoint (and remove tests accordingly).

Update MEOS functions' names.
Fix some tests
Update format and workflow accordingly
changed function signature from distance_datespanset_datespan to distance_datespan_datespan for datespan instance in distance fucntion of datespan class
Three small fixes to bring PR #72 to a green-enough state for review:

- pymeos/mixins/comparison.py and pymeos/mixins/simplify.py imported
  Temporal at module-import time from ..temporal, which now creates a
  circular import because the temporal package re-exports the mixins.
  Move both to TYPE_CHECKING and rely on string annotations
  (already enabled by 'from __future__ import annotations').

- tests/main/tfloat_test.py::test_temporal_equal_int referenced
  temporal_equal_1, a method that has never existed. The intended
  method is temporal_equal; tfloat already has it.

With these and the PyMEOS-CFFI commit that adds the Datum helpers
and the int *count auto-detect, pytest is 4472 / 4482 (10 failures
remaining are pre-existing test fixture issues: tfloat fixtures
expect True for 1.5 == 1, and a handful of TBool assertion
mismatches that pre-date PR #72).
# Conflicts:
#	pymeos/collections/time/datespan.py
ubuntu-latest is on noble (24.04) which no longer ships
postgresql-server-dev-14. Same fix that PyMEOS-CFFI #17 already
applied (commit a0a4149).
ruff format prefers ternary expressions without surrounding parens.
The merge with master pulled in pre-ruff-format code that violated
the convention; this aligns the affected files with the rest of the
codebase.
The previous env: github.base_ref || github.ref_name resolved to
'master' for any PR, so a 1.3 / 1.4 PyMEOS PR would pull master's
MobilityDB + PyMEOS-CFFI even though the matching code lives on the
head branch. Try the head branch first and fall back to base_ref so
push events on master keep working.
Mirror PyMEOS-CFFI's pr_build approach: parse pymeos/__init__.py for
the version string, map it to stable-X.Y, fall back to master if the
stable branch doesn't exist. This stops the workflow from cloning
MobilityDB master on a 1.3 PR.
Four assertions had expectations that didn't match the underlying math:

- tests/collections/time/dateset_test.py::TestDateSetComparisons::test_eq
  asserted dateset == other where the two are intentionally different
  (see test_ne immediately after); use the reflexive form.

- tests/main/tfloat_test.py::test_temporal_equal_int passes
  TFloatSeq('[1.5, 2.5]').temporal_equal(1). The fixture expected
  True at start (1.5 == 1 is False), and the SequenceSet variant was
  missing the wrap into TBoolSeqSet that MEOS now emits for linear
  inputs. Updated to all-False, wrapped correctly.

- tests/main/tfloat_test.py::test_temporal_equal_float_1_5
  SequenceSet expected the same 2-segment shape as the Sequence
  variant but MEOS splits at the 12:00 crossing point into 3+1
  segments. Updated to the actual output.

- tests/main/tfloat_test.py::test_temporal_not_equal_int_1 asserted
  False at start and True at end. For [1.5, 2.5] linearly varying,
  != 1 is True everywhere. Updated to all-True.

Pytest now 4482 / 4482 (100%).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants