Installation Issue of `torch_scatter` in Virtual Environments

[notdian]

Hello torch_scatter team,

I hope this message finds you well. I've recently come across an issue related to the installation process of torch_sparse when working within a virtual environment. Here's a concise description of the problem and a potential solution:

Issue Description:

While attempting to install torch_scatter inside a virtual environment, I noticed that its build process seems to have a dependency on torch.

Steps to Reproduce:

1. Create a new virtual environment.
2. Activate the virtual environment.
3. Try installing torch_scatter via pip. (Note: Installing torch beforehand doesn’t help because pip builds in isolation by default.)

A current workaround is to use the --no-build-isolation flag when using pip. However, this method can introduce other issues and feels like a workaround rather than a clean solution.

Suggested Solution:

I suggest leveraging pyproject.toml as outlined in PEP 518 to define build dependencies. This can ensure that required packages are present during the build process. Here's a potential configuration:

[build-system]
requires = ["setuptools", "wheel", "torch"]

By incorporating this change, users should have a more seamless installation experience, especially in isolated environments like virtual environments.

Thank you for considering this suggestion, and I appreciate all the work you've put into the torch_scatter package!

[Matthias Fey]

Thank you. We will definitely consider this. However, most of this library has been already moved to torch, so it is not a top priority for me right now. Let me know if you have interest in contributing this.

[notdian]

While the proposed solution does address the installation issue, it introduces another challenge: managing the torch version becomes cumbersome due to the limitations of pyproject.toml in handling environment variables and intricate version specifications (ex syncing with install_requires dep versions). An illustrative challenge I've encountered is when dealing with multiple CUDA/torch versions in the github pipelines; utilizing sed is an option, but it becomes convoluted quickly. I'm uncertain if resorting to the torch @ 'url' pattern might be an overreach. Additionally, discrepancies between the torch version used during package build and the one present in a user's repository can potentially result in complications/incompatibilities. For my specific use case, employing scatter_reduce from torch sufficed, hence I question the feasibility of navigating through these complexities, especially for earlier torch versions.