Skip to content

Symlink (or copy) binary entry points into ephemeral environments #14877

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zanieb
Copy link
Member

@zanieb zanieb commented Jul 24, 2025

Closes #14874

In addition to copying entry points and rewriting their shebangs, if we encounter entry points that do not have shebangs (e.g., binaries), we'll symlink (or copy, on Windows) them into the directory.

I'm uncertain if this is the correct approach or if we should change binary discovery in Ruff to account for this case.

@zanieb zanieb added the bug Something isn't working label Jul 24, 2025
@zanieb zanieb temporarily deployed to uv-test-registries July 24, 2025 20:20 — with GitHub Actions Inactive
@zanieb zanieb force-pushed the zb/link-entrypoints branch from 778a833 to c7982af Compare July 24, 2025 20:47
@zanieb zanieb temporarily deployed to uv-test-registries July 24, 2025 20:50 — with GitHub Actions Inactive
@geofft
Copy link
Collaborator

geofft commented Aug 6, 2025

One think to think about with a copy is that executable-relative dependencies will break. This will be fine for symlinks, and so in particular $ORIGIN-relative dependencies will be fine... but is there an equivalent on Windows? I believe Windows executables load .dlls out of their current directory, do people rely on that in stuff shipped in wheels?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

uv run --with can't find installed ruff in subprocess
2 participants