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

3 participants