141–150 of 193 posts
Pypi doesn't need users to manually to fill survey per se, they need to (optionally) prompt "install failed, submit traceback and error code to pypi for solutions" during setup.
If I see some JS, Go, or Rust code online I know I can probably get it running on my machine in less than 5 min. Most of the time, it's a ‘git clone’ and a 'yarn' | 'go install' | 'cargo run', and it just works. With python, it feels like half the time I don't even have the right version of python installed, or it’s somehow not on the right path. And once I actually get to installing dependencies, there are often ver…
What you feel with python is what I feel with JS managing npm and package.json which has dependency issues. With python it always has been pip install package and we are done. Although I do share your pain with versioning. I once spent a week debugging an issue only to find out that there's a fixed version available.
Earlier quoted context omitted.
I like poetry. It still has a way to go though since it is slow as all hell doing almost anything and its error messages are closer to a stack trace than something actionable.
I agree that the stack trace error messages are weird. That aspect feels uncharacteristically hacky for an otherwise pretty polished tool.
If I see some JS, Go, or Rust code online I know I can probably get it running on my machine in less than 5 min. Most of the time, it's a ‘git clone’ and a 'yarn' | 'go install' | 'cargo run', and it just works. With python, it feels like half the time I don't even have the right version of python installed, or it’s somehow not on the right path. And once I actually get to installing dependencies, there are often ver…
What you feel with python is what I feel with JS managing npm and package.json which has dependency issues. With python it always has been pip install package and we are done. Although I do share your pain with versioning. I once spent a week debugging an issue only to find out that there's a fixed version available.
Installing packages, creating a manifest of dependancies, managing virtual environments, packaging, checking/formatting code, etc... should be built into the Python toolchain (the python binary itself). Needing to chose a bunch of third party tools to make it work... makes Python, well... un-pythonic.
Not sure about formatting code, I think that's a job for IDE or text editor, not the runtime. Absolutely agree about the rest of them.
Earlier quoted context omitted.
> Remove setup.py files and mandate wheels What alternative is there for me? My package has a combination of hand-built C extensions and Cython extensions, as well as a code generation step during compilation. These are handled through a subclass of setuptools.command.build_ext.build_ext. Furthermore, I have compile-time options to enable/disable certain configuration options, like enabling/disabling support for Open…
> not add the AVX2 compiler flag It is a better idea to do instruction selection at runtime in the code that currently uses AVX2. I recently wrote some docs for Debian contributors about the different ways to achieve this: https://wiki.debian.org/InstructionSelection
But if the compiler by default doesn't enable AVX2 then it will fail to compile the AVX2 intrinsics unless I add -mavx2.
Even worse was ~10 years ago when I had an SSSE3 code path, with one file using SSSE3 intrinsics.
I had to compile only that file for SSSE3, and not the rest of the package, as otherwise the compiler would issue SSSE3 instructions where it decided was appropriate. Including in code that wasn't behind a CPUID check.
Thus crash on hardware without SSSE3.
See https://stackoverflow.com/questions/15527611/how-do-i-specif... for more info about my solution. Someone last year contributed a solution for MS Windows.
Earlier quoted context omitted.
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. Give…
The 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
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.
Earlier quoted context omitted.
I think some of the pain has been Apple's fault. Requiring conda for some official packages means you always have two competing ecosystems on one machine - which is just asking for pain.
What packages are you referring to? I’ve been doing professional Python dev on a Mac for the past three years and have never had a reason to use conda, so I’m curious what I’m missing.
Earlier quoted context omitted.
> not add the AVX2 compiler flag It is a better idea to do instruction selection at runtime in the code that currently uses AVX2. I recently wrote some docs for Debian contributors about the different ways to achieve this: https://wiki.debian.org/InstructionSelection
I do that, using manual CPUID tests, along with allowing environment variables to override the default path choices. But if the compiler by default doesn't enable AVX2 then it will fail to compile the AVX2 intrinsics unless I add -mavx2. Even worse was ~10 years ago when I had an SSSE3 code path, with one file using SSSE3 intrinsics. I had to compile only that file for SSSE3, and not the rest of the package, as other…
If I see some JS, Go, or Rust code online I know I can probably get it running on my machine in less than 5 min. Most of the time, it's a ‘git clone’ and a 'yarn' | 'go install' | 'cargo run', and it just works. With python, it feels like half the time I don't even have the right version of python installed, or it’s somehow not on the right path. And once I actually get to installing dependencies, there are often ver…
What you feel with python is what I feel with JS managing npm and package.json which has dependency issues. With python it always has been pip install package and we are done. Although I do share your pain with versioning. I once spent a week debugging an issue only to find out that there's a fixed version available.
As a user of an application: `npm install` just works (same with `cargo build`). For Python, I’ll probably do `python -m venv env; . env/bin/activate` and then, well, it’s probably `pip install -r requirements.txt`, but sometimes it’ll be other things, and there are just too many options. I may well add --ignore-installed and use some packages installed locally of potentially different versions, e.g. for setting up Stable Diffusion recently (first time I’ve ever used the dGPU on my laptop) I wanted to use the Arch Linux packages for PyTorch and the likes.
For managing dependencies in an existing library or application (as distinct from starting from scratch, where you’ll have to make several extra choices in Python, and where npm is badly messed up for libraries), both npm and Python are generally fairly decent, but the whole you-can-only-have-one-version-of-a-library thing from Python lends itself more to insurmountable problems.
My personal background: many years of experience with both npm and Python, but I’ve never done all that much packaging in either. (Also many years of Rust, and I have done packaging there, and it’s so much easier than both.)