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

migrate from setup.py to pyproject.toml #287

Closed
jorenham opened this issue Mar 22, 2025 · 9 comments
Closed

migrate from setup.py to pyproject.toml #287

jorenham opened this issue Mar 22, 2025 · 9 comments
Assignees

Comments

@jorenham
Copy link

I'd also recommend uv for pyproject.toml-based project management. That would also allow getting rid of requirements-dev.txt, simplifying the project setup.

But something tells me @lucascolley is going to bring up pixie as an alternative to uv.

@lucascolley
Copy link
Member

lucascolley commented Mar 22, 2025

uv would be good! Buuut... since we are dealing with GPU packages, we are going to want to use libraries like CuPy from conda-forge rather than PyPI (at least for CI, Ralf brought this up at #251 (comment)). At that point, it's probably worth going all in on Pixi.

If somebody wants to contribute a uv setup, I think that would still be a useful contribution! But I don't really have a horse in this race as I rarely develop array-api-compat locally. We can always change stuff like this in the future anyway.

@jorenham
Copy link
Author

Pytorch can be used with uv, and they even have a guide for it: https://docs.astral.sh/uv/guides/integration/pytorch/#installing-pytorch

Jax also shouldn't be a problem, and can nowadays even be used without https://github.com/jorenham/jax_pep503

If I remember correctly, I managed to get dask working within a uv project as well.

And I know for certain that numba works as well.


That's all of the gpu-related stuff, right?

@jorenham
Copy link
Author

If somebody wants to contribute a uv setup, I think that would still be a useful contribution! But I don't really have a horse in this race as I rarely develop array-api-compat locally. We can always change stuff like this in the future anyway.

I'll give it a try

@jorenham jorenham self-assigned this Mar 22, 2025
@lucascolley
Copy link
Member

For sure, you can install and use GPU packages from PyPI. But there are various reasons why, especially from a development perspective, it is better to work with a package manager/distribution which is aware of native dependencies. There is more on this at https://pypackaging-native.github.io/key-issues/gpus/.

@lucascolley
Copy link
Member

Also see #255 before starting work on this @jorenham

@jorenham
Copy link
Author

For sure, you can install and use GPU packages from PyPI. But there are various reasons why, especially from a development perspective, it is better to work with a package manager/distribution which is aware of native dependencies. There is more on this at pypackaging-native.github.io/key-issues/gpus.

Yea that makes sense. But in this project, does that really matter?

@lucascolley
Copy link
Member

I suppose it probably doesn't make a big difference, but just better to follow best practices given the choice 🤷‍♂️

@NeilGirdhar
Copy link
Contributor

Can this be closed by #255?

@ev-br
Copy link
Member

ev-br commented Mar 29, 2025

Indeed, thanks @NeilGirdhar !

@ev-br ev-br closed this as completed Mar 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants