4 ms·

Your comment really isn't adding any value to understanding the state of Python packaging. From my personal experience, there's so many things that can crop up

by vore 5y ago

Your comment really isn't adding any value to understanding the state of Python packaging. From my personal experience, there's so many things that can crop up, not limited to: - Conflicts with system packages from e.g. apt - Conflicts with system packages from easy_install/pip - Mismatching Python versions (even among 3.x with syntax additions only available in newer versions) - Different dependency management systems (pip's requirements.txt, setuptools's setup.py, poetry's pyproject.toml, etc.) - ... and the list goes on if you start talking about C extensions! Additionally, not everyone does things in the same way which means the easiest way to package Python tools tends to be just bundling Python + its entire standard library together. Contrast this with Go, where `go install` does basically the right thing 9 times out of 10. I'm not a huge Go fan, but the convenience of `go install` is really unmatched.

travbrack 5y ago
virtual environments address all these concerns, no?
- danachow 5y ago
  Absolutely not. A virtualenv is typically a pointer to a systemwide python, or something managed by yet another piece of crap - chpy, asdf, whatever - they are not self contained. Upgrading the system python will typically break the virtualenv.
  - nkuttler 5y ago
    Anything, even a statically linked binary can run into problems if you upgrade the entire OS..
    - unionpivo 5y ago
      Not really on linux. I mean if you upgrade from x11 to wazland and zour app depends on x11 then sure, but I still use binaries that were compiled in 90s (some because I dont have the source) And windows is also very backwards compatible.
harel 5y ago
I mentioned this on another reply, but Windows has as far as I remember a way to wrap a Python program as an exe executable. Maybe it's time for python to have a universal go-like binary. Yes, a 1KB program will turn into a 300MB behemoth, but people don't seem to mind it with Electron (I don't usually) so maybe it can work.
nyanpasu64 5y ago
In my experience, `pipx install` (with `--system-site-packages` if you want system Qt themes) generally works as a user, though it breaks when the Python version updates, it doesn't generate a zero-dependency easily-deployed binary, and the packaging ecosystem is indeed a serious problem as a developer. Have you experienced other issues using it?

by vore 5y ago

travbrack 5y ago

virtual environments address all these concerns, no?

danachow 5y ago
Absolutely not. A virtualenv is typically a pointer to a systemwide python, or something managed by yet another piece of crap - chpy, asdf, whatever - they are not self contained. Upgrading the system python will typically break the virtualenv.
- nkuttler 5y ago
  Anything, even a statically linked binary can run into problems if you upgrade the entire OS..
  - unionpivo 5y ago
    Not really on linux. I mean if you upgrade from x11 to wazland and zour app depends on x11 then sure, but I still use binaries that were compiled in 90s (some because I dont have the source) And windows is also very backwards compatible.

harel 5y ago

I mentioned this on another reply, but Windows has as far as I remember a way to wrap a Python program as an exe executable. Maybe it's time for python to have a universal go-like binary. Yes, a 1KB program will turn into a 300MB behemoth, but people don't seem to mind it with Electron (I don't usually) so maybe it can work.

nyanpasu64 5y ago

In my experience, `pipx install` (with `--system-site-packages` if you want system Qt themes) generally works as a user, though it breaks when the Python version updates, it doesn't generate a zero-dependency easily-deployed binary, and the packaging ecosystem is indeed a serious problem as a developer. Have you experienced other issues using it?