4 ms·

Why is python bad for cli applications

tyingq 5y ago
Right from the very first bytes of your cli app you run into issues. The interpreter line. You have to choose #!/usr/bin/python or #!/usr/bin/python2 or #!/usr/bin/python3 (or similar variations with /usr/bin/env). All of these happily ignored by Windows. The latter two may not exist on some platforms. The first one could be invoking either a python2 or python3 interpreter. There's some python magic for determining the version, but if you use a feature not supported by the version it raises an uncatchable exception...because python's parser has control before your code has control. This isn't the only deployment issue, but a good example of what you're in for.
throwaway19937 5y ago
Packaging and deploying Python apps is an adventure.
- 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.
  - 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?
somekyle 5y ago
I_like_ writing CLI apps in Python, and for various reasons haven't been subjected to the packaging woes, but I think execution latency is an important thing for CLI tools, and I've had enough Python CLI tools spend most of their time (a user-perceptible amount) loading modules that I prefer less dynamic languages for tools that aren't completely trivial.
- jen20 5y ago
  It makes sense that _you_ as an author don’t think of python packaging as a problem - it’s only really inflicted upon non-developer end users of the products.
  - somekyle 5y ago
    Oh, I'm sure it's a problem; the reason I haven't been subjected to these problems is because I mostly deploy tools to an environment that has pre-existing build system and deployment solutions for this that I don't have to maintain.
- burnished 5y ago
  Could you write a guide? Pretty please? I've had nothing but woe in this realm, and anytime one asks about this the answers usually contradict each other, or leave out significant detail. I think an article that details your workflow could be tremendously interesting for others.
  - maleldil 5y ago
    What problems do you have with CLI apps? In my experience, the problem is whether you're targeting developers (i.e., people that can run pip install <tool>) or end-users (those that just want to run a binary). Python is hell for the latter. I support Windows and Linux, so I can bend pyinstaller to my will with enough effort, but I need to have a special Windows VM to "cross-compile". For the former, though, it's a matter of creating a setup.py and telling the user to pip install the repo on GitHub. Or you can use Poetry, which makes things slightly easier.

Right from the very first bytes of your cli app you run into issues. The interpreter line. You have to choose #!/usr/bin/python or #!/usr/bin/python2 or #!/usr/bin/python3 (or similar variations with /usr/bin/env). All of these happily ignored by Windows. The latter two may not exist on some platforms. The first one could be invoking either a python2 or python3 interpreter. There's some python magic for determining the version, but if you use a feature not supported by the version it raises an uncatchable exception...because python's parser has control before your code has control. This isn't the only deployment issue, but a good example of what you're in for.

throwaway19937 5y ago

Packaging and deploying Python apps is an adventure.

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.
- 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?

somekyle 5y ago

I_like_ writing CLI apps in Python, and for various reasons haven't been subjected to the packaging woes, but I think execution latency is an important thing for CLI tools, and I've had enough Python CLI tools spend most of their time (a user-perceptible amount) loading modules that I prefer less dynamic languages for tools that aren't completely trivial.

jen20 5y ago
It makes sense that _you_ as an author don’t think of python packaging as a problem - it’s only really inflicted upon non-developer end users of the products.
- somekyle 5y ago
  Oh, I'm sure it's a problem; the reason I haven't been subjected to these problems is because I mostly deploy tools to an environment that has pre-existing build system and deployment solutions for this that I don't have to maintain.
burnished 5y ago
Could you write a guide? Pretty please? I've had nothing but woe in this realm, and anytime one asks about this the answers usually contradict each other, or leave out significant detail. I think an article that details your workflow could be tremendously interesting for others.
- maleldil 5y ago
  What problems do you have with CLI apps? In my experience, the problem is whether you're targeting developers (i.e., people that can run pip install <tool>) or end-users (those that just want to run a binary). Python is hell for the latter. I support Windows and Linux, so I can bend pyinstaller to my will with enough effort, but I need to have a special Windows VM to "cross-compile". For the former, though, it's a matter of creating a setup.py and telling the user to pip install the repo on GitHub. Or you can use Poetry, which makes things slightly easier.