41–50 of 384 posts
* Create a new conda environment with the minimum python version I need to support.
* Use poetry to install dependency
* Package the production build into container image for deployment.
The only problem I have is sometimes Poetry choke on compiling libraries with C-dependency, luckily most libraries provide binary wheel now.
Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? Our project gets a few issues opened by distro maintainers who have trouble with some part of their build process. Is it really worth our project maintainers time to help troubleshoot esoteric build processes when we already provide source, wheel, and conda distributions?
Users generally don't want Python packages; they want software. They don't care what it's written in, and shouldn't have to install it differently depending on what you chose. “Just learn $language_package_manager_of_the_day, and hope it doesn't break anything when your system changes” is the equivalent of the 90s “./configure ; make ; make install”, and we should have moved past that for end-users by now. Most users…
If you’re distributing an application, shouldn’t you just ship an environment with our package bundled?
This is my decision flow and I rarely have an issue: Are you the end user of the Python code? Yes -> Is available in your distro? Yes->Use package manager No->Use pip install in user mode No -> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there Some extreme use cases may benefit from anaconda, but personally I've never needed to use it. My only pain point is dealing with…
Hm, why? I'm a happy user of PYTHONPATH!
I set PYTHONPATH, but the code in that directory is solely small debugging utils of mine that I want available in every Python interpreter, and I make sure not to put anything more complex in there.
Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development. This also applies to many others programming languages which have their own packaging systems. While python packaging is indeed messy the needs of traditional linux distributions are by far the least important. Python packaging needs to better serve the needs of python developers, not those of sysadmins.…
Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? Our project gets a few issues opened by distro maintainers who have trouble with some part of their build process. Is it really worth our project maintainers time to help troubleshoot esoteric build processes when we already provide source, wheel, and conda distributions?
I don't know what I'm doing differently.
This is my decision flow and I rarely have an issue: Are you the end user of the Python code? Yes -> Is available in your distro? Yes->Use package manager No->Use pip install in user mode No -> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there Some extreme use cases may benefit from anaconda, but personally I've never needed to use it. My only pain point is dealing with…
This is a great recipe for disaster. Whatever you install in user mode will shadow anything installed system-wide, so when you try to run some system-wide project, it may now fail. I'm also not a fan of how it drops scripts into `./.local/bin`, since that's where I keep my own script, and is version controlled.
The installation will also be frozen and never get updated -- unless you remember to do it manually.
Finally, and worst of all, this leaves you in a dead end if your packages have conflicting dependencies, which is too often the case in Python-land.
Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. But as a rant this, like most of the ‘but just fix it’ rants, fails to acknowledge the hugely diverging needs of different users. I could not live without conda, since it’s the only sane way to get a working recent geospatial stack. Others need to run embedded environments, or portable ones, som…
I think what it makes it more difficult in the case of Python is that it has decades of legacy to deal with. No consistent semantic versioning, packages that expect that they can modify their package path in-place (this is a nightmare for immutable systems, like NixOS or OSTree-based system like Silverblue), a wide variety of build systems that sometimes hook into make, etc. Solving this is a hard problem.
This is why an authority like PSF has to step in and say: this is how it is going to be done from here onwards.
[1] E.g. Rust's Cargo.
Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development. This also applies to many others programming languages which have their own packaging systems. While python packaging is indeed messy the needs of traditional linux distributions are by far the least important. Python packaging needs to better serve the needs of python developers, not those of sysadmins.…
This is my decision flow and I rarely have an issue: Are you the end user of the Python code? Yes -> Is available in your distro? Yes->Use package manager No->Use pip install in user mode No -> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there Some extreme use cases may benefit from anaconda, but personally I've never needed to use it. My only pain point is dealing with…
Hm, why? I'm a happy user of PYTHONPATH!
My pain point in particular with PYTHONPATH (or playing with sys.path) is that people tend to use it with the only purpose of making import lines shorter, which brings naming collisions of all sorts when you aren't creative enough.