3 ms·
I agree it would be cool and useful. But it appears to be such a hard problem that modern packaging tools ignore it, preferring to take on other challenges ins
by dalke 4y ago
I agree it would be cool and useful.
But it appears to be such a hard problem that modern packaging tools ignore it, preferring to take on other challenges instead.
My own attempts at extracting Python configuration information to generate a Makefile for personal use (because Makefile understand dependencies better than setup.py) is a mess caused by my failure to understand what all the configuration options do.
Given that's the case, when do you think we'll be able to "Remove setup.py files and mandate wheels"?
I'm curious on what evils you're thinking of? I assume the need to run arbitrary Python code just to find metadata is one of them. But can't that be resolved with a pyproject.toml which uses setuptools only for the build backend? So you don't need to remove setup.py, only restrict when it's used, yes?
- infogulch 4y agoThe closest thing I've seen to a solution in this space is Riff, discussed yesterday [1], which solves the external dependency problem for rust projects. [1]: https://news.ycombinator.com/item?id=32739954 https://news.ycombinator.com/item?id=32739954
- dalke 4y agoAgreed. In my answers to the survey, I mentioned "nix" was the technology most likely to affect the future of Python packaging, in part because of reading that same article on Riff. I think now I should have mentioned Riff too.