5 ms·

Packaging and deploying Python apps is an adventure.

by throwaway19937 5y ago

privacyonsec 5y ago
you should try PyInstaller
apple4ever 5y ago
If you are good, you don't have to worry about it. I never have to, because my scripts use packages easily available from pip and I keep them up to date as things change.
harel 5y ago
If you don't know how to do something, everything is an adventure.
- willcipriano 5y ago
  I agree. I've used Python for a decade. Go and Node are a pain in the ass compared to Python, simply because I am unfamiliar with them. Use tox to create a virtualenv and then you can run irrespective of system packages and build the virtualenv in a single 'tox' command.
- 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?
- tshaddox 5y ago
  I think “adventure” implies significant depth into the unknown which one must traverse. A single coin flip is also an unknown but generally wouldn’t be described as an adventure.
  - throwaway19937 5y ago
    Years ago I went on a long distance canoe trip in the Arctic. It rained every day, the mosquitos ate us alive, and I came uncomfortably close to hypothermia. It was a great experience and an adventure - that's what I was thinking of.
- renewiltord 5y ago
  Doing the same for a Go CLI or an Electron app is a walk in the park. I did it in minutes from not knowing anything and it worked on people's computers. I'd choose it any day.
- throwaway19937 5y ago
  I have successfully used CPAN, Maven, NuGet, Homebrew, and other packaging systems while knowing little about them. You can copy a snippet, install the package, and get back to work. Why should Python be any different?

Packaging and deploying Python apps is an adventure.

you should try PyInstaller

If you are good, you don't have to worry about it. I never have to, because my scripts use packages easily available from pip and I keep them up to date as things change.

harel 5y ago

If you don't know how to do something, everything is an adventure.

willcipriano 5y ago
I agree. I've used Python for a decade. Go and Node are a pain in the ass compared to Python, simply because I am unfamiliar with them. Use tox to create a virtualenv and then you can run irrespective of system packages and build the virtualenv in a single 'tox' command.
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?
tshaddox 5y ago
I think “adventure” implies significant depth into the unknown which one must traverse. A single coin flip is also an unknown but generally wouldn’t be described as an adventure.
- throwaway19937 5y ago
  Years ago I went on a long distance canoe trip in the Arctic. It rained every day, the mosquitos ate us alive, and I came uncomfortably close to hypothermia. It was a great experience and an adventure - that's what I was thinking of.
renewiltord 5y ago
Doing the same for a Go CLI or an Electron app is a walk in the park. I did it in minutes from not knowing anything and it worked on people's computers. I'd choose it any day.
throwaway19937 5y ago
I have successfully used CPAN, Maven, NuGet, Homebrew, and other packaging systems while knowing little about them. You can copy a snippet, install the package, and get back to work. Why should Python be any different?