Except if they then have to run it on their machine and the setup instructions start with setting up a venv. I find that a lot of Python software in the ML realm makes no effort to isolate the end user from the complexities of the platform. At best you get a setup script that may or may not create a working venv without manual intervention, usually the latter. It might be more of a Torch issue than a Python one but it still means spending a lot of time messing with the Python environment to get things running.
This may color my perception but the parts of the Python ecosystem I get exposed to as an end user these days feel very hacky. (Not all of it is, though; I remember from my Gentoo days that Portage was rock solid.)
Figuring out venvs was a bit frustrating for me. Particularly since the steps I was following to install a particular app mentioned nothing about them, so I just got an error when I tried to follow their instructions. Thankfully managed to get it figured out, but yeah, definitely wouldn’t have been my first choice for an install method if others were available for that app.
There are reasons why Common Lisp (that I absolutely prefer as well) is still a big thing in AI-related applications. Some of those are listed in your comment.
qWhile true, we are not using the same tools as we did in the 50s. Especially with the very quickly evolving situation of today, half measures and hacks are normal.
Same, so I’ll only answer for me: Python is dependency hell, also breaking existing code with every second update. Hard pass.
Still remembering python 3 release from 17 years ago?
They have breaking changes in their minor versions…
We are no longer in the Python 2 days. You have lots of wiggle room for using the version you want and are rarely forced to use specific releases.
There still plenty of “this version of pytorch doesn’t run reliably with Python 3.12, please use 3.10”, though. It’s not all sunshine and roses.
pytorch is a unique kind of mess
If you’re writing python code you have to deal with versioning, yeah. But the end user basically never has to care.
Except if they then have to run it on their machine and the setup instructions start with setting up a venv. I find that a lot of Python software in the ML realm makes no effort to isolate the end user from the complexities of the platform. At best you get a setup script that may or may not create a working venv without manual intervention, usually the latter. It might be more of a Torch issue than a Python one but it still means spending a lot of time messing with the Python environment to get things running.
This may color my perception but the parts of the Python ecosystem I get exposed to as an end user these days feel very hacky. (Not all of it is, though; I remember from my Gentoo days that Portage was rock solid.)
Figuring out venvs was a bit frustrating for me. Particularly since the steps I was following to install a particular app mentioned nothing about them, so I just got an error when I tried to follow their instructions. Thankfully managed to get it figured out, but yeah, definitely wouldn’t have been my first choice for an install method if others were available for that app.
if they do that’s not release ready software that you should concern yourself with imo. that’s a problem of project maturity not runtime choice
Security issues aside, you can freeze python code to an executable, linux, mac, windows.
Kind of neat IMO. Except the security concerns ofc.
There are reasons why Common Lisp (that I absolutely prefer as well) is still a big thing in AI-related applications. Some of those are listed in your comment.
ML is a very new field and so most programs are not mature, and indeed they can have you messing around with venvs and such.
But most python software people actually used is packaged by a distro already.
ML has been there since the 1950s. What is an old field for you?
qWhile true, we are not using the same tools as we did in the 50s. Especially with the very quickly evolving situation of today, half measures and hacks are normal.
🙄
Python versioning is terrible
I mean, flatpaks are great…
Solving problems you shouldn’t have?
You already have those problems, clearly.
deleted by creator