Switch packaging to uv; enable Python 3.14 via build123d dev branch

[bitranox]

Summary

This branch covers four loosely-related areas of work:

1. Packaging — migrate from poetry/pipx to uv.
2. Python version support — make the project work on Python 3.13 and 3.14, where released build123d 0.10.0 currently can't even install.
3. Bug fixes — three latent bugs that were unrelated to the migration but blocked the test suite or the gfpin CLI entirely.
4. New feature — --no-magnet flag on gfbase and gfbin, plus paired Bash + PowerShell recipe launcher scripts for every tool.

Verified: 26/26 tests pass on Python 3.12 (released build123d 0.10.0), Python 3.13 (build123d git dev branch) and Python 3.14 (build123d git dev branch).

---

1. Packaging: poetry → uv

• Replace the [tool.poetry.*] blocks with PEP 621 [project] metadata and switch the build backend to hatchling.
• SPDX License-Expression: CC-BY-NC-SA-4.0 instead of the free-text License: field.
• Test deps moved to a PEP 735 [dependency-groups] table (uv run --group test pytest).
• [project.scripts] for gfpin / gfbin / gfbase / gfedge.
• poetry.lock removed; uv.lock not committed (added to .gitignore).
• README install section rewritten:
  • How to install uv on Linux/macOS and on Windows (one-liner each).
  • Run without installing: uvx --from gfthings gfbin -h — one-shot, no global state, no pipx install needed.
  • uv tool install gfthings for a persistent CLI install (the equivalent of pipx install).
  • uv sync / uv run developer workflow (incl. uv run --group test pytest).
• Wheel-metadata-checked: the built wheel only declares Requires-Dist: build123d>=0.10.0; uv-only metadata is not baked in, so the project remains PyPI-publishable.

2. Python 3.13 / 3.14 support

The released build123d 0.10.0 transitively pulls vtk, which has no Python 3.13 or 3.14 wheels, so a plain install fails on those interpreters regardless of any of our other changes. To unblock 3.13 / 3.14 the project routes build123d through its upstream dev branch (which depends on cadquery-ocp-novtk and skips vtk entirely) using a marker-conditional [tool.uv.sources] entry:

[tool.uv.sources]
build123d = [
    { git = "https://github.com/gumyr/build123d.git", branch = "dev",
      marker = "python_version >= '3.13'" },
]

Python 3.10–3.12 keep using the released wheel from PyPI.

The dev branch has small API drifts from 0.10.0 that the existing gfthings code tripped on. Each one is fixed with comprehensive inline comments explaining the WHY:

• GFProfile.py — sketch plane orientation. Plane(origin, z_dir) on the dev branch picks a different default x_dir when z_dir is exactly axis-aligned vs. only nearly so. For non-square paths (e.g. width=1, depth=2) path%0 returns exactly (-1, 0, 0) and the resulting y_dir flips, sending the swept profile along world Y instead of Z and collapsing GFProfile to volume 0. Fix: pin x_dir explicitly so the polyline's local +Y always lands on world +Z.
• Bin.py — cavity-floor face selection. When the cavity carve depth equals the box height (1×1 bins), the cavity floor lands exactly on the BinBase top face. The dev-branch boolean leaves two coplanar faces at that Z (the actual cavity floor at ±19.55 and the BinBase top at ±20.75 with a near-degenerate inner edge ring). sort_by(Axis.Z)[-2] picks one or the other depending on internal sort stability, which varies with bin height (h=4/h=6 happen to pick the cavity floor; h=5/h=8 pick BinBase top). When BinBase top is picked, two things break: inner_front_centre lands at Y=−20.75 (bin outer wall) instead of Y=−19.55 (cavity inner wall) — the scoop is then positioned 1.2 mm too far back, with part of it embedded in the wall material — and the floor fillet fails outright because of the degenerate inner edge ring. Fix: select the smallest-area XY face at the cavity-floor Z; that's reliably the cavity floor in every case.
• Bin.py — X-coordinate snap. The midpoint of the front-most X-axis edge can land at X = −2e-9 due to symmetric construction. That exact magnitude/sign, when fed into Locations(...) for the subsequent Scoop placement, triggers an OCCT boolean-ADD bug on the dev branch: the resulting solid is just the scoop alone (the entire bin gets dropped). Other tiny X values (0, +1e-9, −1e-12) all work fine. Fix: snap any sub-µm X value to zero.

3. Latent bug fixes (independent of the dev-branch work)

• gfthings/gfbin.py:25 — SyntaxWarning: invalid escape sequence '\*'. Python 3.14 raises this every run. The literal asterisk in the --loop help string didn't need escaping. One-character fix.
• gfthings/gfpin.py — bin vs pin typo. Lines 37/39 called export_step(bin, ...) and export_stl(bin, ...) with bin (Python's built-in) instead of the local pin. The --vscode path worked, but gfpin -o file.step had never produced output.
• gfthings/Pin.py:16 — TypeError: unsupported operand type(s) for +: 'float' and 'function'. plate_base_height was a constant (2.9) at the time Pin was written; commit e7296b9 turned it into a function (short: bool) -> float for the --short base feature, but Pin was not migrated. Pass False to preserve the original 2.9 mm geometry.

4. New feature: --no-magnet

Adds a --no-magnet flag to both gfbase and gfbin with the obvious meaning: keep screw functionality, skip the magnet pocket.

• gfbase --no-magnet replaces the CounterBoreHole(screw_rad, magnet_rad, magnet_depth) (or CounterSinkHole) inside ScrewSupport with a plain Hole(screw_rad), so the base can still be screwed down but no magnet pocket is drilled.
• gfbin --no-magnet skips both the refined side slots and the unrefined bottom holes inside BinBase. Bins have no screw holes, so the result is a plain base profile.
• Plumbed through ScrewSupport/BaseSquare/BaseGrid (Base.py) and BinBase/Bin/FunkyBin/HalfWallBin (Bin.py) via a new magnet : bool = True parameter on each. Default is True, preserving existing behavior.
• Tests added: test_2x2_base_no_magnet, test_1x1_base_no_magnet, test_4_holes_no_magnet, test_simple_bin_no_magnet, test_simple_bin_no_magnet_unrefined.

5. Recipe launcher scripts (.sh + .ps1)

Each tool gets a paired Bash and PowerShell launcher (gfbin.sh / gfbin.ps1, gfbase.sh / gfbase.ps1, gfedge.sh / gfedge.ps1, gfpin.sh / gfpin.ps1):

• The CLI parameters are declared as variables at the top of the script.
• The output filename is auto-derived from the parameters, so a tweak like NoMagnet=true adds _nomagnet to the name and produces a uniquely-named sibling without clobbering anything.
• Each script just prints the equivalent uvx --from <git URL> <tool> ... command and runs it.

The Bash and PowerShell versions take exactly the same variable names and produce identical CAD output, so a recipe is portable between Linux/macOS and Windows.

Workflow (from the new README section):

cp gfbin.sh   screws-bin-2x2x4.sh        # Linux / macOS  (or Copy-Item .ps1 on Windows)
$EDITOR screws-bin-2x2x4.sh              # tweak the variables
./screws-bin-2x2x4.sh                    # writes screws-bin-2x2x4-derived-name.step

Each script also has a NOTE: block above the GfthingsSource URL pointing out that the URL is currently pinned to the fork's py314compat branch because the 3.13 / 3.14 work is not yet upstream, and listing the two replacements to use after this PR merges (git+https://github.com/PaulBone/gfthings.git while waiting for a release, or just gfthings once a 3.13/3.14-compatible release is on PyPI).

6. Test infrastructure

tests/Utils.py's float_eq epsilon is loosened from 0.001 to 0.05 mm³ to accommodate sub-cubic-millimeter OCCT variance between build123d versions for the same input geometry. The comment on the helper now explains where the variance comes from.

Verified test matrix

Python	build123d source	tests
3.12	PyPI 0.10.0 (released)	26/26 ✓
3.13	git dev branch (via [tool.uv.sources])	26/26 ✓
3.14	git dev branch (via [tool.uv.sources])	26/26 ✓

3.10 / 3.11 use the same resolution path as 3.12 (released build123d 0.10.0); not exercised in CI here but should behave identically.

Note on plain pip install for 3.13 / 3.14

pip ignores [tool.uv.sources], so pip install gfthings on Python 3.13 or 3.14 will still fail to resolve build123d (it tries the released 0.10.0 wheel and hits the missing vtk wheels). uv (uv tool install, uvx --from <git URL>, or uv sync from a checkout) is the supported install path on those interpreters until upstream build123d ships a release that targets 3.13+.