Has anyone solved the compiled libraries / dynamic libraries / linking problems for multiplatform apps? Everything works just fine with these python>native app tools until you hit some esoteric library that's not pure python.
It has a very specific filesystem layout that it calls a package, but this is not a first class citizen; it has a packaging format called "wheel" that is now used for distribution, and that can contain native libraries. That currently mostly handles the distribution of compiled libraries for multiple platforms, but only within the traditional venv-style setup. Being able to ship interpreter+venv+launcher would go a long way towards providing a native-ish experience.
A step beyond that would be being able to distribute a "virtual filesystem" containing a whole tree of python compiled as .pyc, appended to a native executable containing the interpreter and linked against the required native libraries already.
Since venvs on Linux symlink to the system’s Python executable, they should also work after moving.
So…they aren’t then.
So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update.
> Since venvs on Linux symlink to the system’s Python executable
Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.
I don't think the maintainers have gotten a request to do that. Personally I use a more complicated launcher because I need to set things like environment variables in my deployments, but a venv is almost an out-of-the-box relocatable Python environment. It's when you need to protect/compile your code that things get messy.
>> Since venvs on Linux symlink to the system’s Python executable
>Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.
When you call /usr/bin/pythonx.y -m venv ./myenv, ./myenv/bin/python will link to /usr/bin/pythonx.y. Since there aren't many reasons to use a Python version not installed by the package manager, I call these the "system's Python executables", but sure, it can also point to /opt if you installed Python there.
I used that for my own Python+Electron app, which I wrote about here: https://til.simonwillison.net/electron/python-inside-electro...
https://cibuildwheel.readthedocs.io/ is a great tool for assisting with that - many projects run that in GitHub Actions as part of their release process.
There's just one catch, in my experience: since GitHub don't offer Apple Silicon machines as part of GitHub Actions, it can be hard to build wheels there that work on those platforms. Maybe you can cross-compile them? I've not figured that out yet.
I have deep wounds from pre-chatGPT times of trying to manually figure out libraries. As in otooling each library, error, etc then recompiling into various places until things 'worked.' I'm appreciative of the experience, though now I think with LLMs the problem could be solved with some simple queries.
So I guess you're right, it requires effort, but I was a 10x engineer in the wrong direction and never want to experience that again ;)
A lot of places do this nonsense "spend hours configuring your machine" method for projects. The only reason I can think of doing that is "job security" and who wants to keep a job with horrible tooling?
But yeah, it takes effort to do.
In a way, that time was a chapter in 'job security.' Ran out of money, had to let everyone go, and picked up the pieces to fight another day (self-taught under threat of survival). By the grace of God I'm a reformed 'idea-guy' and am now a builder.
Is there ever going to be standardization, the way a WebGL shader just works everywhere?
It makes it really hard to distribute certain python libraries.
As much as I hate how containers are often misused, this is one of the reasons people obsess over them from my experience. The ability to bundle all your crap regardless of how many layers of package management idiosyncrasies your application ultimately woul have to deal with pretty much transparently.