Fail the mlflow-skinny/mlflow-tracing build instead of shipping an empty wheel - #25713

Related Issues/PRs

Closes #25641

What changes are proposed in this pull request?

libs/skinny/mlflow and libs/tracing/mlflow are committed as git symlinks (mode 120000) to the repository's mlflow package. On a Windows checkout without symlink privilege — core.symlinks=false, the default for a non-elevated user with Developer Mode off — git materializes them as plain text files containing the link target, so [tool.setuptools.packages.find] discovers no packages.

The build then exits 0 and produces a wheel with no code in it, which installs cleanly and declares the mlflow console entry point but cannot import anything. A build reporting success while producing nothing is the defect here — worse than one that stops.

This adds a setup.py beside each generated pyproject.toml that stops the build when the linked source is not a directory, and says how to fix the checkout. pyproject.toml is generated by dev/pyproject.py and marked do-not-edit, so the check cannot live there; setuptools still executes setup.py when it sits beside PEP 621 metadata, so the guard runs at build time without changing any packaging configuration.

This is option A from the issue. Not option B (repointing setuptools at the real tree): a better outcome, but a larger change needing care with MANIFEST.in and package-data globs, and it would mean editing generated files. Happy to take that on separately if you'd prefer it.

build-wheel.yml builds both variants on ubuntu-latest, where symlinks resolve, so no job builds either variant on Windows and this is invisible to CI by construction.

How is this PR tested?

• Manual tests

Verified on the exact reported setup: Windows 11, non-elevated, Developer Mode off, core.symlinks=false, on a fresh --depth=1 clone at master.

Before — the silent failure:

$ git ls-files -s libs/skinny/mlflow
120000 01d2913... 0    libs/skinny/mlflow
$ ls -la libs/skinny/mlflow
-rw-r--r-- 12 bytes                      # a regular file, not a directory
$ find_packages(where="libs/skinny", include=["mlflow", "mlflow.*"])
[]
$ build_meta.build_wheel("dist")         # exit 0
entries: 6 | .py files: 0

After — the failure path now fails, through both entry points:

$ build_meta.build_wheel("dist")         # exit 1
$ pip install ./libs/skinny              # exit 1
  libs/skinny/mlflow is not a directory, so this build would produce a wheel
  with no code in it.
  On Windows, git materializes symlinks as text files unless you enable
  Developer Mode, or clone with:
      git -c core.symlinks=true clone https://github.com/mlflow/mlflow

After — the working path is untouched. Standing a junction in for the resolved symlink to reproduce what Linux CI sees, I built the wheel with the guard and without it:

Metadata still comes from pyproject.toml (Name: mlflow-skinny, Version: 3.16.1.dev0), with entry_points.txt and mlflow/__init__.py both present — so setup() with no arguments runs the check without taking over packaging. libs/tracing builds the same way (605 .py files).

Published PyPI artifacts are unaffected: they are built on Linux, where the guard is a no-op.

ruff check and ruff format --check clean at the pinned 0.16.4.

Does this PR require documentation update?

• No.

Does this PR require updating the MLflow Skills repository?

• No.

Release Notes

Is this a user-facing change?

• Yes. Building mlflow-skinny or mlflow-tracing from a source checkout whose symlinks were not materialized (typically Windows without Developer Mode) now fails with an actionable message instead of silently producing a wheel containing no Python modules.

What component(s), interfaces, languages, and integrations does this PR affect?

Components

• area/build: Build and test infrastructure for MLflow

How should the PR be classified in the release notes? Choose one:

• rn/bug-fix - A user-facing bug fix worth mentioning in the release notes

Is this PR a critical bugfix or security fix that should go into the next patch release?

• This PR is critical and needs to be in the next patch release
• This PR can wait for the next minor release

Note on ownership: @siva23367 expressed interest on 09-07 and @kriscon-db noted issues aren't assigned here. I've said on the issue that I'll close this if they already have work in progress — I'd rather not duplicate their effort.