5 ms·

Bummer about Python :/ it’s my go-to for CLI tools, but I’ve seen that problem too.. pipenv helps, but I wonder if there’s a better way to package them so they’

by timwis 5y ago

Bummer about Python :/ it’s my go-to for CLI tools, but I’ve seen that problem too.. pipenv helps, but I wonder if there’s a better way to package them so they’re more future proof.. or do I really need to learn go?

GVRV 5y ago
If the standard tech stack at your organisation includes Python, there's no reason why you shouldn't write CLI tools in Python. Packaging and distribution is only a problem for organisations that do not usually deal with Python.
i_like_apis 5y ago
IMO we loose a lot with go: having to compile, loosing the interactive shell, etc. Best case you work with a lot of people who know how to install python and use pip. Many people whine on boards, but it's not that complicated, especially with python 3.
- cconstantine 5y ago
  > install python and use pip Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.
  - p_l 5y ago
    Not to mention all kinds of python version issues, especially given that botched 2-to-3 migration means there's a lot more Python 2 than there should be.
    - worik 5y ago
      Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
      - burnished 5y ago
        Where does that happen? Honestly I think I only know of open source python stuff, so I'm real curious!
        worik 5y ago
        What is open sauce? My point being to the users of the products we create, software licensing is not what they are thinking about.
        burnished 5y ago
        I'm asking you about this >Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
- shoo 5y ago
  > we loose a lot with go: having to compile If you're concerned about compile time -- Go does a pretty reasonable job of caching (including caching unit test results). If you're working on a Python project with a large number of unit tests, because Python is so slow to execute anything, and the go build and test tools are quite fast, it wouldn't be that surprising if it was actually faster to compile and run the test suite in Go vs running the test suite in Python -- particularly for incremental work where you make a change in one library and rerun the impacted tests. If you're concerned more about the workflow of needing an additional compile step, go has `go run script.go` which lets you use go like a scripting language, assuming you're in an environment with the go toolchain installed.
- pphysch 5y ago
  I used to abuse Python's REPL and realized I was wasting a lot of time in the REPL that could be saved by articulating my tests in a proper test file or even just main(). pkg.go.dev and gopls also automate away most of the "exploration" I would be doing in Python REPL.
shoo 5y ago
I've worked with Python for over a decade and have worked with Go for a few years. The Go tooling and workflow for building and deploying applications is much more pleasant than the Python ecosystem. Once you know which target operating systems and CPU architectures you wish to deploy to, the toolchain makes it very easy to cross compile to produce n deployable binaries, then the static linking means you generally only need to copy 1 binary file to each target, plus your own application configuration. If you have a Python background and have done some programming with a static type system before, then Go is very quick to learn. The Go language itself is a bit annoyingly inexpressive for bashing out algorithms, but that probably doesn't matter if you're writing CLI tools. For packaging python stuff, it kind of depends who or what the end user of the CLI tool is. I used to work in a small business that shipped windows desktop software to customers, a lot of the software was written in python. From memory we packaged it with py2exe -- so you end up building a zip file containing a self-contained executable, the version of the python interpreter your tool needs, along with all the python packages as well as native libraries. That worked quite reliably, but it'd seem rather distasteful to use that approach for sharing CLI tools with your colleagues or CI machines in a dev team! edit: there are pitfalls to deploying go application binaries if you try to put them in scratch containers and use libraries that assume they can find data such as timezone data provided in the usual place in the filesystem by the distribution (there will be no such data files in a scratch container unless you explicitly copy them in), or build a go linux binary with dynamic linking assuming glibc, then try to run it in an alpine based environment with musl. So it's not magic. But it's mostly pretty nice.
- worik 5y ago
  > Once you know which target operating systems and CPU architectures you wish to deploy to If you know that, this is not the problem for you. Often you do not know that. Then this is a huge problem.
harel 5y ago
you need to take advice with a grain of salt. Python is fine for CLI tools, just like Go is fine for them. If you know Python, that weird statement in the article was not for you. I honestly don't get what the problem is. You know Python? You use it for CLI? Power to ya. You know Go? Use it for CLI? Power to ya too.
- number6 5y ago
  I am working with python full-time. I can package a cli so it works on other systems, but I always envied go - just compiles to one file with no dependencies. This makes it a much better choice for cli apps or portable apps. Hey you can always use docker for shipping /s
  - harel 5y ago
    Go is a different animal, and yes it has superb packaging. Shipping a binary is a beautiful thing. I remember windows has some packager for Python creates exe files (pyInstaller?). Maybe it's time for a universal binary executable for python....

by timwis 5y ago

GVRV 5y ago

If the standard tech stack at your organisation includes Python, there's no reason why you shouldn't write CLI tools in Python. Packaging and distribution is only a problem for organisations that do not usually deal with Python.

i_like_apis 5y ago

IMO we loose a lot with go: having to compile, loosing the interactive shell, etc. Best case you work with a lot of people who know how to install python and use pip. Many people whine on boards, but it's not that complicated, especially with python 3.

cconstantine 5y ago
> install python and use pip Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.
- p_l 5y ago
  Not to mention all kinds of python version issues, especially given that botched 2-to-3 migration means there's a lot more Python 2 than there should be.
  - worik 5y ago
    Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
    - burnished 5y ago
      Where does that happen? Honestly I think I only know of open source python stuff, so I'm real curious!
      - worik 5y ago
        What is open sauce? My point being to the users of the products we create, software licensing is not what they are thinking about.
        burnished 5y ago
        I'm asking you about this >Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
shoo 5y ago
> we loose a lot with go: having to compile If you're concerned about compile time -- Go does a pretty reasonable job of caching (including caching unit test results). If you're working on a Python project with a large number of unit tests, because Python is so slow to execute anything, and the go build and test tools are quite fast, it wouldn't be that surprising if it was actually faster to compile and run the test suite in Go vs running the test suite in Python -- particularly for incremental work where you make a change in one library and rerun the impacted tests. If you're concerned more about the workflow of needing an additional compile step, go has `go run script.go` which lets you use go like a scripting language, assuming you're in an environment with the go toolchain installed.
pphysch 5y ago
I used to abuse Python's REPL and realized I was wasting a lot of time in the REPL that could be saved by articulating my tests in a proper test file or even just main(). pkg.go.dev and gopls also automate away most of the "exploration" I would be doing in Python REPL.

shoo 5y ago

I've worked with Python for over a decade and have worked with Go for a few years. The Go tooling and workflow for building and deploying applications is much more pleasant than the Python ecosystem. Once you know which target operating systems and CPU architectures you wish to deploy to, the toolchain makes it very easy to cross compile to produce n deployable binaries, then the static linking means you generally only need to copy 1 binary file to each target, plus your own application configuration. If you have a Python background and have done some programming with a static type system before, then Go is very quick to learn. The Go language itself is a bit annoyingly inexpressive for bashing out algorithms, but that probably doesn't matter if you're writing CLI tools. For packaging python stuff, it kind of depends who or what the end user of the CLI tool is. I used to work in a small business that shipped windows desktop software to customers, a lot of the software was written in python. From memory we packaged it with py2exe -- so you end up building a zip file containing a self-contained executable, the version of the python interpreter your tool needs, along with all the python packages as well as native libraries. That worked quite reliably, but it'd seem rather distasteful to use that approach for sharing CLI tools with your colleagues or CI machines in a dev team! edit: there are pitfalls to deploying go application binaries if you try to put them in scratch containers and use libraries that assume they can find data such as timezone data provided in the usual place in the filesystem by the distribution (there will be no such data files in a scratch container unless you explicitly copy them in), or build a go linux binary with dynamic linking assuming glibc, then try to run it in an alpine based environment with musl. So it's not magic. But it's mostly pretty nice.

worik 5y ago
> Once you know which target operating systems and CPU architectures you wish to deploy to If you know that, this is not the problem for you. Often you do not know that. Then this is a huge problem.

harel 5y ago

you need to take advice with a grain of salt. Python is fine for CLI tools, just like Go is fine for them. If you know Python, that weird statement in the article was not for you. I honestly don't get what the problem is. You know Python? You use it for CLI? Power to ya. You know Go? Use it for CLI? Power to ya too.

number6 5y ago
I am working with python full-time. I can package a cli so it works on other systems, but I always envied go - just compiles to one file with no dependencies. This makes it a much better choice for cli apps or portable apps. Hey you can always use docker for shipping /s
- harel 5y ago
  Go is a different animal, and yes it has superb packaging. Shipping a binary is a beautiful thing. I remember windows has some packager for Python creates exe files (pyInstaller?). Maybe it's time for a universal binary executable for python....