Remove committed uv.lock so the env resolves the latest ogcore

[SeaCelo]

uv.lock was committed automatically during the conda→uv migration, and it pins ogcore to the migration-era 0.15.13. So the documented setup does not pull the latest ogcore — on main, uv sync installs 0.15.13 (and even downgrades a newer install) even though 0.16.1 is released.

git checkout main
uv sync --extra dev
uv run python -c "import ogcore; print(ogcore.__version__)"

This stops committing uv.lock, so uv sync resolves the pyproject floors freshly → latest compatible (ogcore 0.16.1 today, new releases as they land). pyproject.toml keeps the ogcore>=… floor for compatibility (what package consumers already use); the lock is regenerated locally and git-ignored.

• Removes uv.lock, adds it to .gitignore, updates the AGENTS.md convention.
• Verified: uv sync now resolves ogcore 0.16.1; pytest -m 'not local' passes (27).
• CI uses plain uv sync (no --frozen/--locked), so nothing breaks.

cc: @rickecon @jdebacker

(Same change as OG-ETH #51.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.34%. Comparing base (2e349f4) to head (a2f8e5b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #116   +/-   ##
=======================================
  Coverage   78.34%   78.34%           
=======================================
  Files          15       15           
  Lines         799      799           
=======================================
  Hits          626      626           
  Misses        173      173           

Flag	Coverage Δ
unittests	78.34% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jdebacker]

@SeaCelo Thanks for thinking about this.

Wouldn't another (maybe preferable) solution be to keep tracking uv.lock, but have a dependabot running in this repo to update package versions as they are released?

cc @rickecon

[SeaCelo]

@jdebacker its a great question and happy to apply either one. I thought of this approach because I dont see any good reason to lock to a specific ogcore version. That is something a user may want to do for a given paper/project (reproducibility).

[jdebacker]

@SeaCelo I just committed a dependabot.yml to the repo in the .githhub directory.

This will help us keep uv.lock up to date (on a weekly basis) with any updates to package dependencies.

Note that uv.lock is just there to ensure that results are exactly reproducible with what is in a given state of the main branch. Users can feel free to use different versions of any package (including ogcore) and can create their own uv based environments and save them for reproducibility of their specific version of the model and dependencies. They only need to activate their uv environment and pip install a specific version of whatever package they would like.

Let me know if this is satisfactory and we can close this PR.

[SeaCelo]

Sounds good @jdebacker — happy to go with the Dependabot route and close this one.

One pending gap on the current dependabot.yml as committed: It only has npm, docker, and github-actions ecosystems, and we don't have a package.json or Dockerfile, so the first two are no-ops — only the Actions updates will run. To get the weekly uv.lock/ogcore bumps you described, it needs a uv ecosystem entry:

  - package-ecosystem: "uv"
    directory: "/"
    schedule:
      interval: "weekly"

Also worth a one-time uv lock --upgrade — the lock still pins ogcore 0.15.13 (0.16.1 is out), so main won't pick up the latest until that first bump lands.

Once the config here is settled, we should mirror the same uv entry across the other country repos so they're all actually tracking ogcore updates and not silently pinned.

[jdebacker]

Replaced by PR #122.