Skip to content
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

Support "--no-build-isolation" when installing packages #1715

Closed
Taytay opened this issue Feb 19, 2024 · 13 comments · Fixed by #2258
Closed

Support "--no-build-isolation" when installing packages #1715

Taytay opened this issue Feb 19, 2024 · 13 comments · Fixed by #2258
Assignees
Labels
compatibility Compatibility with a specification or another tool enhancement New feature or improvement to existing functionality installer Related to package installation

Comments

@Taytay
Copy link

Taytay commented Feb 19, 2024

uv --version: 0.1.5

This is an official issue to track a separate issue discovered in #1582. It was requested to be tracked separately here: #1582 (comment)

Short version:

Without --no-build-isolation, many popular ML libraries, including flash-attn can't be pip installed.
I want to be able to do this:

uv pip install flash-attn --no-build-isolation

But I can't.

If uv pip install doesn't support this, I don't think that it will support installing some popular ML and Deep Learning python modules.

Disclaimer

I just discovered this stuff in about 1 hour of reading, and my python-dependency knowledge is pretty poor. I think this is a good description of the issue, but know that this is NOT coming from an expert.

Long version

The "newer" versions of pip enable build-isolation by default when modules are being installed. (BIG discussion here for those interested in the history: pypa/pip#8437)
This is generally pretty nice, because it allows a python module to request a newer version of setuptools or something at install time, without polluting a user's global environment by permanently installing an undesired newer version of a module.
The downside is that it hides all existing installed modules from the module's setup.py script.
The typical solution to this is to tell pyproject.toml about the modules required at setup time. It will install them in the isolated environment, and then proceed with the installation.

There is a bigger downside though:

A number of machine learning-related modules Flash-attn, NVidia Apex need pytorch to be installed before they are installed, so that they can do things like compile against version of pytorch currently installed in the user's environment.

You might think that these modules should declare that they depend upon Pytorch at setup time in their pyproject.toml file, but that isn't a good solution. No one wants a newly installed Pytorch version, and they might have installed pytorch using Conda or some other mechanism that pip isn't aware of. And these modules want to just work with whatever version of pytorch is already there. It would cause a LOT more problems than it would solve.

So, modules like these simply instruct users to disable this build isolation by running pip install with --no-build-isolation. Problem solved! But uv doesn't support this. (As discovered in #1582).

(This issue generally manifests as an error when setup.py can't being find the packaging module, and users being confused because they already ran pip install packaging. See: Dao-AILab/flash-attention#453
That's exactly the error I get when I uv pip install flash-attn: ModuleNotFoundError: No module named 'packaging'

@zanieb zanieb added enhancement New feature or improvement to existing functionality compatibility Compatibility with a specification or another tool installer Related to package installation labels Feb 19, 2024
@ilkersigirci
Copy link

ilkersigirci commented Feb 20, 2024

I hope this is fixed soon since flash-attn is the barebone for my ML projects :(

@charliermarsh charliermarsh self-assigned this Feb 20, 2024
@charliermarsh
Copy link
Member

We'll support it. Assigning to myself.

@gaborbernat
Copy link
Contributor

gaborbernat commented Feb 20, 2024

So, modules like these simply instruct users to disable this build isolation by running pip install with --no-build-isolation. Problem solved!

I'd call this a workaround, not a problem solved... and note this approach would not be endorsed by the PyPA. I wonder though why these tools can't do ensure pytorch is installed inside the build wheel isolated environment, and they must have access to the target Python instead.

@hmc-cs-mdrissi
Copy link

hmc-cs-mdrissi commented Feb 20, 2024

Numpy is more foundational library with similar interesting workarounds (oldest-supported-numpy). What build isolated environment has doesn't really matter because today there's no way to say that build environment and runtime environment for library must be same. These libraries care about runtime version of pytorch that will be used. They may support older pytorch versions, but build process can do optimizations specific to actual pytorch used at runtime. The pytorch present at build time does not matter to them. So build isolation here is in direct conflict with this use case.

A packaging standard here would ideally be a way for specific dependencies to specify that their build vs runtime version are same. Most dependencies isolation is fine, only rare few that are sensitive to this.

edit: If your intent is access to target python to dynamically inspect runtime pytorch that may work, but also seems like violation of intent of build isolation and would still leave a separate pytorch in build environment as not needed.

@hauntsaninja
Copy link
Contributor

Yeah, +1 to the problem mdrissi mentions. --no-build-isolation is really useful to allow us to ensure that a build of PyTorch in the build environment is the exact same build that is in the runtime environment. Without this you get linker issues.

The PyPI ecosystem doesn't really work well for this kind of thing. We have custom logic that wraps and handles all of this stuff at work (e.g. it uses things like #1415 as an escape hatch). Although note we don't actually use pip install --no-build-isolation, we do python -m build --no-isolation since we prebuild all this stuff. Our custom logic actually gets quite interesting, if you're curious I'd be happy to talk more about it when y'all are less swamped.

@konstin
Copy link
Member

konstin commented Feb 22, 2024

If we could guarantee that we install the install the same pytorch version in the build env as in the target env (assuming we manage the target env torch version) and we reflink/hardlink so installing is fast and doesn't take disk space, would that work for you? I don't think we can cover all use cases that --no-build-isolation supports, but i'd like to support isolation for as many cases as possible

@marcelroed
Copy link

I hope this is fixed soon since flash-attn is the barebone for my ML projects :(

This is the only issue keeping me from using uv for everything.

@charliermarsh
Copy link
Member

PR is up: #2258

@marcelroed
Copy link

marcelroed commented Mar 7, 2024

Wow, thanks @charliermarsh! Will test this on flash-attn as soon as it lands in main.

charliermarsh added a commit that referenced this issue Mar 7, 2024
## Summary

This PR adds support for pip's `--no-build-isolation`. When enabled,
build requirements won't be installed during PEP 517-style builds, but
the source environment _will_ be used when executing the build steps
themselves.

Closes #1715.
@charliermarsh
Copy link
Member

This just went out in v0.1.16. Feedback welcome as always.

@shiyangcao
Copy link

Hi,

I'm finding that --no-build-isolation makes it so that nothing in the pyproject.toml is processed.

For example, we have this pyproject.toml

  1
  2 [build-system]
  3 requires = [ "setuptools>=41", "wheel", "setuptools-git-versioning<2", "packaging"]
  4 build-backend = "setuptools.build_meta"
  5
  6 [tool.setuptools-git-versioning]
  7 enabled = true
  8 dev_template = "{tag}.{ccount}+g{sha}"
  9

When we use uv pip install -e . the version is something like 1.2.3. However, when we use --no-build-isolation, it goes to 0.0.0

Is there a way to assume that the dependencies are already installed, but still run setuptools-git-versioning etc?

Thanks

@hcoona
Copy link

hcoona commented Aug 14, 2024

May I know how to install flash-attn with uvx?

I tried uvx --with torch --with flash-attn --no-build-isolation insanely-fast-whisper but got the error: (uv 0.2.36)

warning: `uvx` is experimental and may change without warning
⠙ nvidia-cusparse-cu12==12.1.0.106                                                                                      error: Failed to download and build `flash-attn==2.6.3`
  Caused by: Failed to build: `flash-attn==2.6.3`
  Caused by: Build backend failed to determine metadata through `prepare_metadata_for_build_wheel` with exit status: 1
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 14, in <module>
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 174, in prepare_metadata_for_build_wheel
    self.run_setup()
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 267, in run_setup
    super(_BuildMetaLegacyBackend,
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 158, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
  File "setup.py", line 21, in <module>
    import torch
ModuleNotFoundError: No module named 'torch'
---
  Caused by: This error likely indicates that flash-attn==2.6.3 depends on torch, but doesn't declare it as a build dependency. If flash-attn==2.6.3 is a first-party package, consider adding torch to its `build-system.requires`. Otherwise, `uv pip install torch` into the environment and re-run with `--no-build-isolation`.

@charliermarsh
Copy link
Member

@hcoona -- I think this isn't possible right now. I'll file an issue about it. I think you'll have better luck using uv tool install, like:

uv venv
uv pip install torch
uv tool install flash-attn --no-build-isolation --python .venv

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with a specification or another tool enhancement New feature or improvement to existing functionality installer Related to package installation
Projects
None yet
Development

Successfully merging a pull request may close this issue.