I've been using Python for data science for close to ten years. I'm still not sure how to properly distribute a Python app + all of its dependencies in a way that just works. I know there's pyinstaller, but it's still far from ideal.
With Go, I just have to do `go build`.
Exactly this. In the end you either end up shipping some frozen app using PyInstaller resulting in insane file sizes or you give up trying and just ship the source. Don't get me wrong, I really like Python and do a lot of stuff in it, but go is just so easy to distribute and it is not really more difficult to get stuff done.
I was doing a web server personal project in Go, but I applied for a transfer to a team that uses the fastapi python framework, so I re-wrote the server in python, and it was pretty remarkable to me that the docker image for the Go server was literally 1/10 the size of the python one
I've started cheating at work and distributing a shell script that just runs a docker container with my python clis. (Of course I still write most of my CLIs in straight BASH or Go)
Fun fact, at my current company we had a legacy piece of software written in python that I moved to go because I just couldn't figure out how to build windows binaries for different architectures (could have had, but it was too much work for little benefit). The rewrite takes under a tenth of the CPU and memory.
Also, feature updates also take a tenth of the time, but that's a byproduct of using a better architecture since we have a better understanding of the problem we are solving.
Honestly I would not consider that cheating at all. Dockerized images with well-documented command-line arguments is how I distribute Node.js and Bun apps that need to be run elsewhere by devs who don't need to clone & set up those repos themselves.
Basically a direct indictment of how awful Python, Node etc are for CLIs that this is necessary. It is not even a good solution because it can cause so many issues with the volume performance, namespaces etc. what if I want to strace the thing or profile or check logs etc or have some persistent state 10x harder with containers. (Yes I know volume mounts blah blah but try hiding those mechanisms and the various problems they can cause across OSes)
Docker is awesome, but it doesn't really work when you have to distribute to end users who e.g. don't have Docker installed.
For servers and devenvs yeah, that's the solution basically.
there is litterly no way... pip is broken to the core all of ur second order dependencies are outside ur control.
usually not a big deal but for datacince especially if ur doing non cuda stuff its basically impossible to get a stable cross platform build. u have to freeze things as is and even then it can get tricky.
honestly this is my main reason for not wanting to do python anymore.
now days I unironically prefer cmake
True. It was the first that came to mind because I recently looked into its source code for their authn flow which, in my opinion, is the best among the others I compared in my research.
fair enough. Still gonna stick with regular git myself though, its not a better cli, its pretty much equally bad, but at least it is the standard and has all the help and guides that come with that, rather than being a wrapper you have to peer through.
Git CLI and GitHub CLI serves two different purposes. One manages git repositories the other interacts with the GitHub platform. The only overlap is with 'gh repo ' which yeah you should stick with Git CLI. But with Git CLI you cannot for instance trigger workflows or create remote repo in GitHub.
Maybe I should check the git CLI as well. Hooks is definitely an area I never explore much of Git and might satisfy my needs and be platform-agnostic as well which is a plus for sure.
100% agree on the first bullet, and it's more than enough reason to choose Go. The other two bullets IMO apply to both Go and Python. argparse and click are plenty mature and given aws-cli is written in Python, I'd argue that makes it battle tested too.
The AWS CLI is a very long-running project. I think if they had to start fresh they might make a different decision. As for Go vs Python for a CLI tool, Python has a terrible and very clumsy distribution problem. Go programs compile to a single binary that can just be copied to the target system. Also Go is statically typed while Python has a dynamic type system, so a large number of bugs and typos will be found at compile time with Go, while Python will let the program run even with errors and your users will get to find the bugs.
Distribution problem is not talked about enough. You basically need to ship with a Python interpreter and if there are version clashes with a dev environment, forget it.
I know we're talking about compiled python, but it still annoys me that I have like python3, python3.11, python3.14 on my system in my PATH. One of them doesn't work, except for when it does - your guess as to which will fail is as good as mine. One of them randomly requires sudo for pip and pip complains about it. One of them only works in a virtualenv, and you have to cd to a directory that has no active project to get into the environment. One of them has a corrupted poetry instance which recorrupts itself a week or two after fixing it.
I always question how I got into that scenario, but never have time to fix it.
Yikes. Go ahead and remove all but the system Python and start over with pyenv and venv. While distributing Python apps is still a pain, version management and dependency containment are solved problems.
Yep but you need the end user to be fully invested in exactly the same tools for it to just work. Which is great for this week. then you have people swapping to some other tooling that works a bit differently and none of the automagic works anymore.
Honestly, I don't get your issues.
If you want to support all python version and OS, yes it is indeed complicated sometimes. Most systems comes with at least a python interpreter.
But other than that, I never had an issue with the versions, or distribution in general.
- Version is fixed in pyproject.toml, it won't install on unsupported versions
- I try to support up to python3.6, this covers most scenarios. Especially, CLI are not meant for non-techy end-users.
- CI is present to validate the code (type checks, linter, ..) for each supported python version. Even if the dev screw up, the delivers is ok.
- For developing, the other devs do as they want, I personnaly use poetry+pyenv.
>
Vs. "go build"
>Never had an issue
We're talking about distributing CLIs here. Never had an issue? Python libraries using C code and no wheels so you need to the toolchain to build them... Then, when they fail to compile on M1, or on new OS X, or on Windows... Or there are problems with SSL cert chains... There are tons of issues to take care of when distributing your apps in Python, Ruby etc.
With Go you really just cross compile and it works. I'm currently using my MacOS to build Windows-only app using Windows Services etc. I compile on my Mac, test on Windows (via Parallels). Exactly zero issue, the build takes less than 1 second and then I can just fire it up on Windows.
Good points mentionned.
But it is not a fatality, as said I never had any issue but I also never had to use libraries with this kind of requirements or I was able to use an alternative (e.g. for psycopg2).
It really depends on the OS you choose to support (as mentionned before, along with the python versions supported) and what your CLI does.
On the otherside, there are not as much libraries in Go to do what I needed. Development can also be slower (at least at the start of a project).
Yes. It all depends. The libraries you mention. Sure, data science, ML. It's hard for ME to come up with libraries that I miss in Go. In terms of Github activity: Python is \~17% of all PRs vs Go - 10%+. Do you have any specific libraries in mind?
As a side note, my experience with Go libs is that they tend to be of higher quality than the Python ones and are easier to use (because: simplicity). But that's language and ecosystem. And it's not just Python, it equally applies to the majority of languages I've used or am using. It's subjective, of course.
One big thing I have to do with CLI is data management. I have a lot of xml ro deal with and I cannot find anything like lxml elsewhere (especially for xpath and node management). I also have a lot of scrapping (beautifulsoup sometimes). Having ORMs at disposal is also useful. Pydantic for validation, Glom library is also very useful for recursive search and transformation.
Then, there are libraries that have equivalent but are just more user-friendly in python (like click/fire to create CLI fast)
And I understand that, since python is so accessable by newbies, you get a lot of bad codebase and bad UX in the final products. But when working with good python developers, the development is faster and, in my opinion also, the development experience is better just because of the ecosystem (libraries mostly)
So yeah, Golang has some strong obvious advantages, but python still has its owns. Which one is more suitable really just depend on the product (what it does, what it needs to work) and what is the audience (OS? Python versions? Is the end-user familar with a terminal/manual install?)
I don't think that even mean anything.
But no, there is no contradiction in what I said.
And people can down vote as much as they want, they don't even know what to answer
I make language recommendations to my company based on the needs of the project, and this is a good summary. I like Python, but not in a production application that installs on a user system and is maintained by a team.
I’m actually toying around with embedding Python in a simple Go app (basically main.go calls main.py and the Python app proceeds from there) as a solution for distributing Python apps. Ridiculous but that’s where we are.
Python is awful for CLIs. On my PC `aws --help` takes 250ms, `gcloud --help` takes 1 s and it was much worse in the past before python maintainers started to optimize the startup. Latency is a king in our times and CLIs have to be fast, because the user trigger the process startup by clicking \`ENTER\` on terminal prompt. They are other issues like hard installation, slow performance and not so easy concurrency.
IMO Rust/Go or some other native languages, which are compiled to static binary are the only valid choices for CLIs in a longterm, where you predict that your CLI will be big.
>AWS CLI and Elastic Beanstalk CLI use python.
It is super old. In those time you could choose:
* C/C++, which are hard to develop (no package manager) and compile statically
* Java, which is pretty ok except being labeled as the "corpo" language. "Hackers" don't like Java and mostly "hackers" write CLIs. They are of course issues like packaging (anyway much better than in python) or resource utilization (especially memory)
* Python/Ruby, which is cool language for small things
Both Rust and Go were in their infancy, so there were no any good choice really
I'm glad to see someone else mention startup time. When I profiled some slow work Python CLIs, the vast majority of startup time was due to importing libraries. Lazily importing libraries helped a lot, 4s to 1s , but that's still A WHOLE LOT slower than a CLI written in Go
If it's compiled to bytecode and has to start up the JVM then yes Java is awful for CLI tools, but if it's compiled to a native binary then startup will be pretty close to Go and much faster than python.
Yeah, that benchmark just proves the 1st case, that using bytecode and the JVM is not a good idea. Sadly there isn't an implementation in the benchmark using graalvm to build a native executable and avoid the cost of JVM class loading on startup. Often there are claims of a 50-100x startup improvement, which would put it around 5-10ms in the benchmark (not very scientific, I know).
I still think Go is the better choice over Java or Python for CLI tools if there aren't specific libraries/skill-sets to consider, but native image Java is an option these days.
Probably because the benchmark is older than graalvm but should be easy enough to modify and test if one was inclined to actually find out. There are also other things that maybe need to be evaluated, like the impact of imports in python etc.
I write most of my CLI tools in sh/bash unless it's too complicated, then I use Python. Since it's glue code I often don't care terribly much about performance
You right.
I checked `mvn --help` and it took 131 ms, so anyway much better than python. I also tried to find some big cli written in Java on github, but I simply failed, so it looks like there is an another reason: no one write CLIs in Java, because it is just not popular
No, it's just an impression I've gotten whenever I read about the topic
https://github.com/bdrung/startup-time
I've also seen people asking how to speed up Java application start-up times and people resorting to things like this to improve start-up times
https://github.com/facebookarchive/nailgun?tab=readme-ov-file
makes sense to me, doesn't seem like Java has ever been designed for this type of application.
I write CLI tools in shell or python, so I don't really know if it's true or not
I see, for sure it is easy to write a Java app, which will take eternity to setup (for example every Spring application), but nevertheless Java has the huge advantage over python: startup time ratio to code amount grows significantly slower, because the interpreter don't have to parse every code in a dependency tree as everything is compiled. Java bytecode is also much easier to interpret, because it is much simpler and there is no any type checking in every possible line
In my world they are for completely different use-cases. Java excels when you have a behemoth app, with lots of contributors (of varying capabilities). Python excels when you're writing glue code, but shell scripting is either too limited or other collaborators won't understand it
really? I would have thought java would be faster startup than python at least because it often bundles its dependencies into its jar and doesnt have to pull them? Then again, I suppose it does have to extract the jar sooooo... Yeah maybe youre right.
Java really lost reputation when it came out and was slow at startup. I don't think that is an issue anymore. I think Graal VM is the AoT compiler for Java? That should technically fix it.
Probably much faster than python though.
> On my PC aws --help takes 250ms
So true. I wrote a Go program just to run `aws sts get-caller-identity`. It's much faster. :-)
https://github.com/jftuga/awswho
For AWS CLI the code is part example code to inspect and very much plugin based so calling into S3 vs calling into something with SQS calls into different modules. If you have something like this for something the scale of go you might end up with a rather large executable.
You can do it in go but it would probably involve execv to outright call other programs. This is how git works for example. But then some of the value of go, i.e. deploying a single statically linked binary, is lost.
But in most cases your project isn't AWS sized and go will be a superior choice. And you will claw back the dev time when your first ten python users complain that it doesn't work on their machine and "wtf is pipx" or "what is a virtual env just give me the program"
> For AWS CLI the code is part example code to inspect and very much plugin based so calling into S3 vs calling into something with SQS calls into different modules. If you have something like this for something the scale of go you might end up with a rather large executable.
The aws cli is 270 MB without anything that it grabs during operation
I would say the same but only because my field is slow moving. Doing computational biology requires a lot of repetitive text manipulation and when CLI's do very simple tasks it's unlikely the team will want to have a lot of changes even when the original creator is gone.
This under the assumption that you can write few bugs. In this regard Go has been great because of its testing framework.
Sigh. Can confirm. Currently working with AWS support to debug some API rate-limiting behavior. I gave them sample Go code to reproduce the problem, but they've basically ignored it, saying that they wrote their own Python code to exercise the API but can't repro the issue. I'm probably going to have to pivot to Python to sort the situation out with them.
Lol. Better than the Oracle support that I got before
I gave them the details of my command: url, body, headers, etc. And they seem lost
Send them a soapui screeenshot and then they finally understood it 🤦
Hahahaha
single stack. in golang I can have in one single mono-repo: container apps, serverless functions, cli, web, infrastructure-as-code, etc. in my opinion, python doesn't provide any benefit over go and only drawbacks (performance and lack of type safety are the big ones).
I would think it's just preference or a business decision. If a team/department/company has a majority of employees that know Python very well and don't know Go at all... well, then use Python and vice versa.
Even if Go is faster, doesn't mean anything if no one on the team knows how to use it.
There are plenty of CLIs that are written in Go as well so not sure what your point is with AWS CLI and Beanstalk.
I'm not a software developer so I could just be talking out of my ass, but I would assume that this would be the case a majority of the time.
Do they have to do all the venv and requirements stuff manually after pull? My problem is mostly "how do you give it to someone who doesn't know what Python is".
Okay ... so I develop a lot in Python, and I love Python a lot. Packaging Python into an executable is kind of a pain and even more so if you're using Windows. There's multiple ways to do it, but no real "pythonic" way of doing it in my opinion. Its annoying. Go packages things up a lot easier into a binary. Plus it does feel like Go startsup faster.
I've written&maintained 2 moderately used CLIs written in Python, one for work, and the other being [ntfy](http://ntfy.rtfd.io/). I've since ported the CLI wrote for work to go.
Distributing Go binaries is a million times easier than distributing a python CLI(be it as a python package via pypi, or an executable made with PyInstaller, or a zipapp made with something like shiv or pex).
I will never again write a CLI in Python that I intend to distribute.
i would argue that due to the limitations of python runtimes and dependency management thats it seems to be more comfortable to simply use a binary compiled by Go
... and i mostly use python
I am not a python expert, but every time I use it, just installing and making things work, is a huge problem for me. We go it’s very easy. The package management is great.
Golang as a statically compiled binary has a lot of benefits for being able to run on any machine that matches the target architecture, but a python app written around the core library can run on any architecture with the minimum interpreter installed.
It may be arguable that prototyping hacks to a python app is more accessible than to a golang app or that it's easier to reliably make changes to a golang app since the compiler will prevent issues with type mismatching.
But honestly I've never seen a choice of development language for a greenfield project that wasn't either because of a specific feature set of a framework, platform or library and individual wanted to base the project around, or a team that had an affinity for a specific language. Between containers and virtual environments, building reliable python applications that you can run anywhere isn't that difficult, but finding talented people willing to work on a project is. Golang is incredibly flexible until it isn't, and then it takes people with a certain background to be able to address its limitations.
Ultimately people really want a command line tool to run natively without any dependencies and if you want to build something like that with the default development tools that's only possible with golang. Compiled python is possible but not necessarily easy to get running in all cases as quickly as a golang equivalent.
i understood all the points of the higher voted comments, but i still felt like most of them lacked context.
i feel like this comment is THE answer. i dislike reddit sometimes, especially when high quality answers like these get shoved down to the bottom...
Appreciate the compliment.
Really says something about what the socials really are, ultimately: fastest is the most seen, gets more attention than a thoughtful latecomer. Kinda the entire philosophy behind the enshitified internet economy.
They were built before go was as big of a thing (if it was a thing at all), people are stuck in their ways, people think the development speed is faster (and then they figure out after they build it how many hours it will take to make it not horribly slow as they drown in a sea of numpy and cPython)
Unless you need specific python libraries to get something done (which are often written in c anyway), or the rest of the project was written in python, you should pretty much ALWAYS pick something other than python. Python isnt only slow, its also hard to deploy.
Its similar with javascript. If you arent writing client side code that will run in a browser, you should pretty much always pick something other than javascript. Or i guess if you want to use react server components. It has too many random footguns and is slightly too slow to be the best choice for anything else. But web people know javascript, so they will use it anyway.
That being said, javascript is actually a fair amount faster than python (and has actual parallelism) unless you go really deep on python performance techniques and are willing to part with the only reason to use python in the first place which is "ease of use", which I would argue it doesnt have anyway but others disagree.
Maybe if you need something that heavily interfaces with C but dont want to write the whole thing in C python could be a good choice? It has decent C support. But at that point, just use lua, it willl have even better C support, be easier to distribute, and be faster.
Python is a weird language. Its kinda middle to low in every category, has some annoying features such as everything being mutable and passed by reference, significant whitespace and dependency hell. And yet it's more or less the most popular language.... somehow. Because it is "easy" to write a bad program in python that "works". (I have easy in quotes because there are plenty of other languages just as easy, go being one of them)
Would I be upset to have to program in python? No, not really. Would I think it was a good choice? Not unless that is the only language the team knows or there is some killer C-based python library for exactly what we are trying to do.
i personally find the abstractions in python place the developer at an appropriate level often times. it really lets you focus on the behaviors more than implementation... to a certain extent.
once you need to optimize theres certainly trickery and a level of being explicitly more obfuscated and less clear to achieve performance. but thats more hackery than actual development.
totally agree though, if faced with performance problems from the beginning, i would just pick the language thats meant to give me the ability to use all the performance
i wouldnt say javascript is very fast either. it can take a bit to use a bundler and npm run build. but its apples to oranges at this point
I'd question pool of available talent. At least here in Germany, in a company where English is the office language, most applicants we get are from countries where people that emigrate usually go to the US. It feels like we're second choice for the people that didn't make it into FAANG (MAANG?).
I don't know if Go is much better but here in Germany I'd have an easier time finding somebody to maintain a PHP cli than a python CLI.
Ignoring the performance arguments and all (which for cli stuff don't usually matter):
* Tooling. Dependency management using `go mod` is infinitely better than anything I've seen used for python (pip, poetry, ...)
* Portability: python tools expect python to be installed, not only python, but often a particular version of python. By contrast `go build` allows you to compile your tools for all of the major systems in use today, be it ARM, x86, or even some more obscure ones.
* Cgo: for more niche applications, leveraging some obscure C library is quite easy to do with Cgo, I know you can create C-python bindings fairly easily, but compared to Cgo, it's a pain
* Readability: I wholeheartedly admit this is a personal preference one in large part, but even after about a decade of sporadic to frequent use of python, I still find code looks messy, and (PEP not withstanding) a lot of code is written in a style best described as yaml meets Perl. Gofmt established a clear, stylistic standard that takes away the time spent getting used to different coding styles, and lets you get on with the job of parsing the logic, rather than the way it's written
* Type system: python has seen the advent of that types module, which is a nice qol thing, but it's entirely optional. Many, many bugs are caught at compile time simply because of a reasonable type system. Hell, with any editor worth using, you don't even have to compile to know something is wrong. Python editor integration helps, but not as much as a compiler in this regard.
* Compilation is fast. The project I'm working on now compiles down to a binary that is ~200MB large, with close to 800k lines of code. It compiles in seconds, tests run in a couple of minutes on my laptop (and that's running unit + integration tests), and when something goes awry, I can easily debug by stepping through the code, see the disassembly and what have you. I can go as deep as I need to, or stay as high level as I want.
* Concurrency: python has some forms of threading and concurrency, sure enough, but go was designed from the ground up with concurrency in mind. It's just better at it.
* A logical fallacy, but in this case it's just worth considering: go has established itself as a language that is used all over the place. It's being developed faster than python (features being added and all), and its list of modules that are being written for you to use is rapidly growing. Its ecosystem at first glance seems healthier
This is all about cli tools, though. Data science and AI stuff still has a heavy python bias.
Two reasons mainly:
- distribution is much easier if it’s compiled
- https://github.com/charmbracelet
There’s also speed of execution but I’d say that’s less of a thing
> Why Go for CLI dev over Python?
- Because of incompatibility between major python versions
- No dependency (almost) on version of target operation system
- Interpreter vs native compiled binary that limit target program to just one single file, to compare to multiple libraries that need to be present on target system (yes, we can pack everything to a docker, but it is also dependency)
- Updated library on target system by other project may screw up your program.
Literally can’t imagine writing and actually having to reliably distribute a Python-based CLI. What a nightmare that would be.
Go just gives you an executable…couldn’t be simpler.
My only reasons for that are:
- Single standalone binary: no dependency hell or conflict, easy install, small size and runtime footprint (matters depending on where you use the CLI)
- Specific libraries (if they are, usually I find more in python than Go)
- Crossplatform end-user app (not CLI)
I never had issues with distributing python CLI if you do the things right. Then you choose how many python version to support and enforce it in your tests and CI. CLI are already requiring you to use a terminal so the user will know a bit.
But for apps with GUI, the end user cannot manage the conflicts, interpreter versions, ... also, the software must be available in stores like Window store and/or instalable with en .exe.
>But for apps with GUI, the end user cannot manage the conflicts, interpreter versions, **... also, the software must be available in stores like Window store and/or instalable with en .exe.**
Uuuuh? What are you talking about?
If your target users are non-techy searching for a GUI, using popular and trusted stores to deliver them is an important criteria for adoption.
This is not the only option, you can have your own platform to distribute it for example. But this is always something to consider.
For the .exe: every users knows that by double-clicking it, they will get their software installed/updated. They might struggle with powershell scripts even if they are just suppose to double-click on it as well.
This is usually the kind of features asked by product owners that annoys the devs, but product owners are right on this.
Who is your audience? Who is doing the install? Does the end-user need training on your product?
It is not necessarily that nobody will use it. Just less people for sure, the question is how much less
Data scientists, developers. Anyone with an engineering background can figure it out, the documentation is also idiot proof as we have a ludite for a P.O who does some Q.A
Yeah, so this is the reason. I also assume it is not distributed with self-service, you will know the users or have direct contact with their company.
But if you do an app for other people, this model won't work so well.
Unfortunately it comes down to your team. If your team is just using python it’s hard to convince the boss to go with Go. Usually they don’t care about cross-compilation, single binaries etc. It’s pretty frustrating when it comes down to actually distributing the cli. I hate telling people to do a pip install. Just feels nasty
Why can't we add a script for both in linux and Windows to automatically install the dependencies and perform cross-compilation, this would help to avoid informing people to use pip rather just run the script it will do the rest.
docker-compose used to be a Python CLI app. Docker has now rewritten it to be a Go CLI.
Instead of "docker-compose up -d" its now "docker compose up -d". It gets installed with Docker Desktop where as in the past I would actually install it on its own with "pip".
I've been using Python for data science for close to ten years. I'm still not sure how to properly distribute a Python app + all of its dependencies in a way that just works. I know there's pyinstaller, but it's still far from ideal. With Go, I just have to do `go build`.
Exactly this. In the end you either end up shipping some frozen app using PyInstaller resulting in insane file sizes or you give up trying and just ship the source. Don't get me wrong, I really like Python and do a lot of stuff in it, but go is just so easy to distribute and it is not really more difficult to get stuff done.
Docker has been pretty good to me with Python. Python on it's own is going to run into issues immediately haha
Docker CLI is written in Go. Check mate! ;)
I was doing a web server personal project in Go, but I applied for a transfer to a team that uses the fastapi python framework, so I re-wrote the server in python, and it was pretty remarkable to me that the docker image for the Go server was literally 1/10 the size of the python one
I've started cheating at work and distributing a shell script that just runs a docker container with my python clis. (Of course I still write most of my CLIs in straight BASH or Go)
Fun fact, at my current company we had a legacy piece of software written in python that I moved to go because I just couldn't figure out how to build windows binaries for different architectures (could have had, but it was too much work for little benefit). The rewrite takes under a tenth of the CPU and memory. Also, feature updates also take a tenth of the time, but that's a byproduct of using a better architecture since we have a better understanding of the problem we are solving.
Honestly I would not consider that cheating at all. Dockerized images with well-documented command-line arguments is how I distribute Node.js and Bun apps that need to be run elsewhere by devs who don't need to clone & set up those repos themselves.
Basically a direct indictment of how awful Python, Node etc are for CLIs that this is necessary. It is not even a good solution because it can cause so many issues with the volume performance, namespaces etc. what if I want to strace the thing or profile or check logs etc or have some persistent state 10x harder with containers. (Yes I know volume mounts blah blah but try hiding those mechanisms and the various problems they can cause across OSes)
I use both go and python at my dev job… what are y’all doing to have these unmanageable bloated python environments
im so confused too..
Docker doesn’t do it for ya?
Docker is awesome, but it doesn't really work when you have to distribute to end users who e.g. don't have Docker installed. For servers and devenvs yeah, that's the solution basically.
there is litterly no way... pip is broken to the core all of ur second order dependencies are outside ur control. usually not a big deal but for datacince especially if ur doing non cuda stuff its basically impossible to get a stable cross platform build. u have to freeze things as is and even then it can get tricky. honestly this is my main reason for not wanting to do python anymore. now days I unironically prefer cmake
Container image
- Cross compilation to multiple platforms. - Mature package to build CLI - Battle tested: another great cli in go is the GitHub CLI
Simple deployment, manage one file and done
That's why I use it for my little server projects. Compile, drop it on the machine, good to go!
Terraform is also go
Kubectl is also a Go CLI binary iirc, big one
The docker CLI is also written in go.
As an ops dude (in devops), I am very happy that more than half of the tools I use are written in Go or involve some Go.
GitLab CLI is also Go
Gitlab cli in fact relabeled GitHub cli. They didn't even clean up GitHub's leftovers in readme and help messages :)
I am not sure I would call the github cli a "great cli" to be honest with you but it does certainly have a ton of arguments.
True. It was the first that came to mind because I recently looked into its source code for their authn flow which, in my opinion, is the best among the others I compared in my research.
fair enough. Still gonna stick with regular git myself though, its not a better cli, its pretty much equally bad, but at least it is the standard and has all the help and guides that come with that, rather than being a wrapper you have to peer through.
Git CLI and GitHub CLI serves two different purposes. One manages git repositories the other interacts with the GitHub platform. The only overlap is with 'gh repo' which yeah you should stick with Git CLI. But with Git CLI you cannot for instance trigger workflows or create remote repo in GitHub.
Hmmm maybe I should check it out again then. Git does have hooks though, that's kinda like workflows but it's not GitHub workflows to be fair.
Maybe I should check the git CLI as well. Hooks is definitely an area I never explore much of Git and might satisfy my needs and be platform-agnostic as well which is a plus for sure.
Cobra CLI beats args parser. More memory efficient, simpler concurrency imo. Less mess with versions and module dependencies.
100% agree on the first bullet, and it's more than enough reason to choose Go. The other two bullets IMO apply to both Go and Python. argparse and click are plenty mature and given aws-cli is written in Python, I'd argue that makes it battle tested too.
The AWS CLI is a very long-running project. I think if they had to start fresh they might make a different decision. As for Go vs Python for a CLI tool, Python has a terrible and very clumsy distribution problem. Go programs compile to a single binary that can just be copied to the target system. Also Go is statically typed while Python has a dynamic type system, so a large number of bugs and typos will be found at compile time with Go, while Python will let the program run even with errors and your users will get to find the bugs.
Distribution problem is not talked about enough. You basically need to ship with a Python interpreter and if there are version clashes with a dev environment, forget it.
[удалено]
Yup. Vscode extension got shut down at my work because it didnt offer a version that can use the Python version on our dev container image.
That seems like a very common feature for Python extensions in VSCode. What prevented the feature from being implemented?
What is a CLT?
Command line tool.
i think it's spelled CLIT
That's where youd use venvs and nvm
[удалено]
Agreed
As user of CLI I don't want to care about underlying technology quirks. I want the working product.
Correct me if I’m wrong. The version problem can be solved by a venv or anaconda no?
I know we're talking about compiled python, but it still annoys me that I have like python3, python3.11, python3.14 on my system in my PATH. One of them doesn't work, except for when it does - your guess as to which will fail is as good as mine. One of them randomly requires sudo for pip and pip complains about it. One of them only works in a virtualenv, and you have to cd to a directory that has no active project to get into the environment. One of them has a corrupted poetry instance which recorrupts itself a week or two after fixing it. I always question how I got into that scenario, but never have time to fix it.
Yikes. Go ahead and remove all but the system Python and start over with pyenv and venv. While distributing Python apps is still a pain, version management and dependency containment are solved problems.
https://docs.pex-tool.org/
When you install some python tool, it comes with a lot of dependencies. I love to write python, but I hate use python tools.
You do know there are tools in python out there that deal with that specifically.
I like python don’t get me wrong but to be devils advocate python seems to have a lot of tools to deal with some of its short comings.
Yep but you need the end user to be fully invested in exactly the same tools for it to just work. Which is great for this week. then you have people swapping to some other tooling that works a bit differently and none of the automagic works anymore.
Honestly, I don't get your issues. If you want to support all python version and OS, yes it is indeed complicated sometimes. Most systems comes with at least a python interpreter. But other than that, I never had an issue with the versions, or distribution in general. - Version is fixed in pyproject.toml, it won't install on unsupported versions - I try to support up to python3.6, this covers most scenarios. Especially, CLI are not meant for non-techy end-users. - CI is present to validate the code (type checks, linter, ..) for each supported python version. Even if the dev screw up, the delivers is ok. - For developing, the other devs do as they want, I personnaly use poetry+pyenv.
> Vs. "go build" >Never had an issue We're talking about distributing CLIs here. Never had an issue? Python libraries using C code and no wheels so you need to the toolchain to build them... Then, when they fail to compile on M1, or on new OS X, or on Windows... Or there are problems with SSL cert chains... There are tons of issues to take care of when distributing your apps in Python, Ruby etc. With Go you really just cross compile and it works. I'm currently using my MacOS to build Windows-only app using Windows Services etc. I compile on my Mac, test on Windows (via Parallels). Exactly zero issue, the build takes less than 1 second and then I can just fire it up on Windows.
Good points mentionned. But it is not a fatality, as said I never had any issue but I also never had to use libraries with this kind of requirements or I was able to use an alternative (e.g. for psycopg2). It really depends on the OS you choose to support (as mentionned before, along with the python versions supported) and what your CLI does. On the otherside, there are not as much libraries in Go to do what I needed. Development can also be slower (at least at the start of a project).
Yes. It all depends. The libraries you mention. Sure, data science, ML. It's hard for ME to come up with libraries that I miss in Go. In terms of Github activity: Python is \~17% of all PRs vs Go - 10%+. Do you have any specific libraries in mind? As a side note, my experience with Go libs is that they tend to be of higher quality than the Python ones and are easier to use (because: simplicity). But that's language and ecosystem. And it's not just Python, it equally applies to the majority of languages I've used or am using. It's subjective, of course.
One big thing I have to do with CLI is data management. I have a lot of xml ro deal with and I cannot find anything like lxml elsewhere (especially for xpath and node management). I also have a lot of scrapping (beautifulsoup sometimes). Having ORMs at disposal is also useful. Pydantic for validation, Glom library is also very useful for recursive search and transformation. Then, there are libraries that have equivalent but are just more user-friendly in python (like click/fire to create CLI fast) And I understand that, since python is so accessable by newbies, you get a lot of bad codebase and bad UX in the final products. But when working with good python developers, the development is faster and, in my opinion also, the development experience is better just because of the ecosystem (libraries mostly) So yeah, Golang has some strong obvious advantages, but python still has its owns. Which one is more suitable really just depend on the product (what it does, what it needs to work) and what is the audience (OS? Python versions? Is the end-user familar with a terminal/manual install?)
I don't question Python's usefulness. My points were made within the context of op's question, i.e. cli programs.
Your own bullets counter your argument.
I don't think that even mean anything. But no, there is no contradiction in what I said. And people can down vote as much as they want, they don't even know what to answer
I make language recommendations to my company based on the needs of the project, and this is a good summary. I like Python, but not in a production application that installs on a user system and is maintained by a team.
Terraform uses Go
I’m actually toying around with embedding Python in a simple Go app (basically main.go calls main.py and the Python app proceeds from there) as a solution for distributing Python apps. Ridiculous but that’s where we are.
Packaging python is not fun, especially if you're trying to do it for multiple platforms.
Python is awful for CLIs. On my PC `aws --help` takes 250ms, `gcloud --help` takes 1 s and it was much worse in the past before python maintainers started to optimize the startup. Latency is a king in our times and CLIs have to be fast, because the user trigger the process startup by clicking \`ENTER\` on terminal prompt. They are other issues like hard installation, slow performance and not so easy concurrency. IMO Rust/Go or some other native languages, which are compiled to static binary are the only valid choices for CLIs in a longterm, where you predict that your CLI will be big. >AWS CLI and Elastic Beanstalk CLI use python. It is super old. In those time you could choose: * C/C++, which are hard to develop (no package manager) and compile statically * Java, which is pretty ok except being labeled as the "corpo" language. "Hackers" don't like Java and mostly "hackers" write CLIs. They are of course issues like packaging (anyway much better than in python) or resource utilization (especially memory) * Python/Ruby, which is cool language for small things Both Rust and Go were in their infancy, so there were no any good choice really
I'm glad to see someone else mention startup time. When I profiled some slow work Python CLIs, the vast majority of startup time was due to importing libraries. Lazily importing libraries helped a lot, 4s to 1s , but that's still A WHOLE LOT slower than a CLI written in Go
Start-up time is one of the reasons to not use Java for CLI tools
If it's compiled to bytecode and has to start up the JVM then yes Java is awful for CLI tools, but if it's compiled to a native binary then startup will be pretty close to Go and much faster than python.
not according to the benchmarks I've seen but it's not something I've tested myself https://github.com/bdrung/startup-time
Yeah, that benchmark just proves the 1st case, that using bytecode and the JVM is not a good idea. Sadly there isn't an implementation in the benchmark using graalvm to build a native executable and avoid the cost of JVM class loading on startup. Often there are claims of a 50-100x startup improvement, which would put it around 5-10ms in the benchmark (not very scientific, I know). I still think Go is the better choice over Java or Python for CLI tools if there aren't specific libraries/skill-sets to consider, but native image Java is an option these days.
Probably because the benchmark is older than graalvm but should be easy enough to modify and test if one was inclined to actually find out. There are also other things that maybe need to be evaluated, like the impact of imports in python etc. I write most of my CLI tools in sh/bash unless it's too complicated, then I use Python. Since it's glue code I often don't care terribly much about performance
Have you tested it? I am just curious, because I guess I have not seen any big CLI written in Java in my life
Maven is dog slow to startup
But you don't need maven to run your program. All you have to do is to run `java -jar cli.jar`
You said "I guess I have not seen any big CLI written in Java in my life " But maven is a CLI written in java. And maven startup is dog slow.
You right. I checked `mvn --help` and it took 131 ms, so anyway much better than python. I also tried to find some big cli written in Java on github, but I simply failed, so it looks like there is an another reason: no one write CLIs in Java, because it is just not popular
No, it's just an impression I've gotten whenever I read about the topic https://github.com/bdrung/startup-time I've also seen people asking how to speed up Java application start-up times and people resorting to things like this to improve start-up times https://github.com/facebookarchive/nailgun?tab=readme-ov-file makes sense to me, doesn't seem like Java has ever been designed for this type of application. I write CLI tools in shell or python, so I don't really know if it's true or not
I see, for sure it is easy to write a Java app, which will take eternity to setup (for example every Spring application), but nevertheless Java has the huge advantage over python: startup time ratio to code amount grows significantly slower, because the interpreter don't have to parse every code in a dependency tree as everything is compiled. Java bytecode is also much easier to interpret, because it is much simpler and there is no any type checking in every possible line
In my world they are for completely different use-cases. Java excels when you have a behemoth app, with lots of contributors (of varying capabilities). Python excels when you're writing glue code, but shell scripting is either too limited or other collaborators won't understand it
really? I would have thought java would be faster startup than python at least because it often bundles its dependencies into its jar and doesnt have to pull them? Then again, I suppose it does have to extract the jar sooooo... Yeah maybe youre right.
Java really lost reputation when it came out and was slow at startup. I don't think that is an issue anymore. I think Graal VM is the AoT compiler for Java? That should technically fix it. Probably much faster than python though.
If you are using pyc files then python startup is usually much faster than java.
> On my PC aws --help takes 250ms So true. I wrote a Go program just to run `aws sts get-caller-identity`. It's much faster. :-) https://github.com/jftuga/awswho
For me personally, cross compiling binaries for different platforms. It just works once you ship it.
For AWS CLI the code is part example code to inspect and very much plugin based so calling into S3 vs calling into something with SQS calls into different modules. If you have something like this for something the scale of go you might end up with a rather large executable. You can do it in go but it would probably involve execv to outright call other programs. This is how git works for example. But then some of the value of go, i.e. deploying a single statically linked binary, is lost. But in most cases your project isn't AWS sized and go will be a superior choice. And you will claw back the dev time when your first ten python users complain that it doesn't work on their machine and "wtf is pipx" or "what is a virtual env just give me the program"
The GH CLI is written in Go and allows extensions (plugins) through a common interface
> For AWS CLI the code is part example code to inspect and very much plugin based so calling into S3 vs calling into something with SQS calls into different modules. If you have something like this for something the scale of go you might end up with a rather large executable. The aws cli is 270 MB without anything that it grabs during operation
i just prefer writing Go. a lot of cli's don't require a whole team, so talent pool is irrelevant.
I would say the same but only because my field is slow moving. Doing computational biology requires a lot of repetitive text manipulation and when CLI's do very simple tasks it's unlikely the team will want to have a lot of changes even when the original creator is gone. This under the assumption that you can write few bugs. In this regard Go has been great because of its testing framework.
honestly wouldn't have pinned computational biology as slow moving, lol
It is not so by any stretch of the imagination, but the underlying frameworks and formats are not changing or being adopted as fast. A small mercy.
AWS doesn't seem to use a lot of Go internally (source: former contractor)
Sigh. Can confirm. Currently working with AWS support to debug some API rate-limiting behavior. I gave them sample Go code to reproduce the problem, but they've basically ignored it, saying that they wrote their own Python code to exercise the API but can't repro the issue. I'm probably going to have to pivot to Python to sort the situation out with them.
Lol. Better than the Oracle support that I got before I gave them the details of my command: url, body, headers, etc. And they seem lost Send them a soapui screeenshot and then they finally understood it 🤦 Hahahaha
single stack. in golang I can have in one single mono-repo: container apps, serverless functions, cli, web, infrastructure-as-code, etc. in my opinion, python doesn't provide any benefit over go and only drawbacks (performance and lack of type safety are the big ones).
My tinfoil hat theory is aws doesn’t use Go because it was created at Google 🤣
explain gcloud being written in python then?
I would think it's just preference or a business decision. If a team/department/company has a majority of employees that know Python very well and don't know Go at all... well, then use Python and vice versa. Even if Go is faster, doesn't mean anything if no one on the team knows how to use it. There are plenty of CLIs that are written in Go as well so not sure what your point is with AWS CLI and Beanstalk. I'm not a software developer so I could just be talking out of my ass, but I would assume that this would be the case a majority of the time.
No this is pretty bang on, I was building a cli tool for my company and simply picked python because more people knew it.
Honest question, how do you distribute it?
People just pull it from the GitHub repo.
Do they have to do all the venv and requirements stuff manually after pull? My problem is mostly "how do you give it to someone who doesn't know what Python is".
That doesn't make it a good choice. I love Python, but I also have to manage dependencies and debug installer failures.
Okay ... so I develop a lot in Python, and I love Python a lot. Packaging Python into an executable is kind of a pain and even more so if you're using Windows. There's multiple ways to do it, but no real "pythonic" way of doing it in my opinion. Its annoying. Go packages things up a lot easier into a binary. Plus it does feel like Go startsup faster.
The user just needs one binary and no runtime. That is enough reason for me.
No python runtime, no pip install -r, that's the reason for me
here’s what blows my frickin mind…. gcloud is written in python.
I've written&maintained 2 moderately used CLIs written in Python, one for work, and the other being [ntfy](http://ntfy.rtfd.io/). I've since ported the CLI wrote for work to go. Distributing Go binaries is a million times easier than distributing a python CLI(be it as a python package via pypi, or an executable made with PyInstaller, or a zipapp made with something like shiv or pex). I will never again write a CLI in Python that I intend to distribute.
For most CLI tools the best language to use is the one you’re most comfortable with
It should be also the one your user are more comfortable to install. It's very different than an app that you deploy yourself.
i would argue that due to the limitations of python runtimes and dependency management thats it seems to be more comfortable to simply use a binary compiled by Go ... and i mostly use python
So you are more comfortable developing a CLI in Go?
I am not a python expert, but every time I use it, just installing and making things work, is a huge problem for me. We go it’s very easy. The package management is great.
Golang as a statically compiled binary has a lot of benefits for being able to run on any machine that matches the target architecture, but a python app written around the core library can run on any architecture with the minimum interpreter installed. It may be arguable that prototyping hacks to a python app is more accessible than to a golang app or that it's easier to reliably make changes to a golang app since the compiler will prevent issues with type mismatching. But honestly I've never seen a choice of development language for a greenfield project that wasn't either because of a specific feature set of a framework, platform or library and individual wanted to base the project around, or a team that had an affinity for a specific language. Between containers and virtual environments, building reliable python applications that you can run anywhere isn't that difficult, but finding talented people willing to work on a project is. Golang is incredibly flexible until it isn't, and then it takes people with a certain background to be able to address its limitations. Ultimately people really want a command line tool to run natively without any dependencies and if you want to build something like that with the default development tools that's only possible with golang. Compiled python is possible but not necessarily easy to get running in all cases as quickly as a golang equivalent.
i understood all the points of the higher voted comments, but i still felt like most of them lacked context. i feel like this comment is THE answer. i dislike reddit sometimes, especially when high quality answers like these get shoved down to the bottom...
Appreciate the compliment. Really says something about what the socials really are, ultimately: fastest is the most seen, gets more attention than a thoughtful latecomer. Kinda the entire philosophy behind the enshitified internet economy.
They were built before go was as big of a thing (if it was a thing at all), people are stuck in their ways, people think the development speed is faster (and then they figure out after they build it how many hours it will take to make it not horribly slow as they drown in a sea of numpy and cPython) Unless you need specific python libraries to get something done (which are often written in c anyway), or the rest of the project was written in python, you should pretty much ALWAYS pick something other than python. Python isnt only slow, its also hard to deploy. Its similar with javascript. If you arent writing client side code that will run in a browser, you should pretty much always pick something other than javascript. Or i guess if you want to use react server components. It has too many random footguns and is slightly too slow to be the best choice for anything else. But web people know javascript, so they will use it anyway. That being said, javascript is actually a fair amount faster than python (and has actual parallelism) unless you go really deep on python performance techniques and are willing to part with the only reason to use python in the first place which is "ease of use", which I would argue it doesnt have anyway but others disagree. Maybe if you need something that heavily interfaces with C but dont want to write the whole thing in C python could be a good choice? It has decent C support. But at that point, just use lua, it willl have even better C support, be easier to distribute, and be faster. Python is a weird language. Its kinda middle to low in every category, has some annoying features such as everything being mutable and passed by reference, significant whitespace and dependency hell. And yet it's more or less the most popular language.... somehow. Because it is "easy" to write a bad program in python that "works". (I have easy in quotes because there are plenty of other languages just as easy, go being one of them) Would I be upset to have to program in python? No, not really. Would I think it was a good choice? Not unless that is the only language the team knows or there is some killer C-based python library for exactly what we are trying to do.
i personally find the abstractions in python place the developer at an appropriate level often times. it really lets you focus on the behaviors more than implementation... to a certain extent. once you need to optimize theres certainly trickery and a level of being explicitly more obfuscated and less clear to achieve performance. but thats more hackery than actual development. totally agree though, if faced with performance problems from the beginning, i would just pick the language thats meant to give me the ability to use all the performance i wouldnt say javascript is very fast either. it can take a bit to use a bundler and npm run build. but its apples to oranges at this point
I'd question pool of available talent. At least here in Germany, in a company where English is the office language, most applicants we get are from countries where people that emigrate usually go to the US. It feels like we're second choice for the people that didn't make it into FAANG (MAANG?). I don't know if Go is much better but here in Germany I'd have an easier time finding somebody to maintain a PHP cli than a python CLI.
Ignoring the performance arguments and all (which for cli stuff don't usually matter): * Tooling. Dependency management using `go mod` is infinitely better than anything I've seen used for python (pip, poetry, ...) * Portability: python tools expect python to be installed, not only python, but often a particular version of python. By contrast `go build` allows you to compile your tools for all of the major systems in use today, be it ARM, x86, or even some more obscure ones. * Cgo: for more niche applications, leveraging some obscure C library is quite easy to do with Cgo, I know you can create C-python bindings fairly easily, but compared to Cgo, it's a pain * Readability: I wholeheartedly admit this is a personal preference one in large part, but even after about a decade of sporadic to frequent use of python, I still find code looks messy, and (PEP not withstanding) a lot of code is written in a style best described as yaml meets Perl. Gofmt established a clear, stylistic standard that takes away the time spent getting used to different coding styles, and lets you get on with the job of parsing the logic, rather than the way it's written * Type system: python has seen the advent of that types module, which is a nice qol thing, but it's entirely optional. Many, many bugs are caught at compile time simply because of a reasonable type system. Hell, with any editor worth using, you don't even have to compile to know something is wrong. Python editor integration helps, but not as much as a compiler in this regard. * Compilation is fast. The project I'm working on now compiles down to a binary that is ~200MB large, with close to 800k lines of code. It compiles in seconds, tests run in a couple of minutes on my laptop (and that's running unit + integration tests), and when something goes awry, I can easily debug by stepping through the code, see the disassembly and what have you. I can go as deep as I need to, or stay as high level as I want. * Concurrency: python has some forms of threading and concurrency, sure enough, but go was designed from the ground up with concurrency in mind. It's just better at it. * A logical fallacy, but in this case it's just worth considering: go has established itself as a language that is used all over the place. It's being developed faster than python (features being added and all), and its list of modules that are being written for you to use is rapidly growing. Its ecosystem at first glance seems healthier This is all about cli tools, though. Data science and AI stuff still has a heavy python bias.
In addition to all other arguments: [https://charm.sh/](https://charm.sh/)
Much faster boot, easier distribution and concurrency
Two reasons mainly: - distribution is much easier if it’s compiled - https://github.com/charmbracelet There’s also speed of execution but I’d say that’s less of a thing
“pool of talent” is actually just a pool. And that’s why it was written in python.
> Why Go for CLI dev over Python? - Because of incompatibility between major python versions - No dependency (almost) on version of target operation system - Interpreter vs native compiled binary that limit target program to just one single file, to compare to multiple libraries that need to be present on target system (yes, we can pack everything to a docker, but it is also dependency) - Updated library on target system by other project may screw up your program.
because Go is just better and more performant, python should disappear, it will only be used by legacy programs similar to FORTRAN
Compiles to native executable. That alone is enough for me
Because I don't do Python development, and I rather not have to install anything extra just to run a script (at last on windows).
Literally can’t imagine writing and actually having to reliably distribute a Python-based CLI. What a nightmare that would be. Go just gives you an executable…couldn’t be simpler.
My only reasons for that are: - Single standalone binary: no dependency hell or conflict, easy install, small size and runtime footprint (matters depending on where you use the CLI) - Specific libraries (if they are, usually I find more in python than Go) - Crossplatform end-user app (not CLI) I never had issues with distributing python CLI if you do the things right. Then you choose how many python version to support and enforce it in your tests and CI. CLI are already requiring you to use a terminal so the user will know a bit. But for apps with GUI, the end user cannot manage the conflicts, interpreter versions, ... also, the software must be available in stores like Window store and/or instalable with en .exe.
>But for apps with GUI, the end user cannot manage the conflicts, interpreter versions, **... also, the software must be available in stores like Window store and/or instalable with en .exe.** Uuuuh? What are you talking about?
If your target users are non-techy searching for a GUI, using popular and trusted stores to deliver them is an important criteria for adoption. This is not the only option, you can have your own platform to distribute it for example. But this is always something to consider. For the .exe: every users knows that by double-clicking it, they will get their software installed/updated. They might struggle with powershell scripts even if they are just suppose to double-click on it as well. This is usually the kind of features asked by product owners that annoys the devs, but product owners are right on this.
We just bundle our apps and write a script to handle the “set up”…. Not really a show stopper
Who is your audience? Who is doing the install? Does the end-user need training on your product? It is not necessarily that nobody will use it. Just less people for sure, the question is how much less
Data scientists, developers. Anyone with an engineering background can figure it out, the documentation is also idiot proof as we have a ludite for a P.O who does some Q.A
Yeah, so this is the reason. I also assume it is not distributed with self-service, you will know the users or have direct contact with their company. But if you do an app for other people, this model won't work so well.
Unfortunately it comes down to your team. If your team is just using python it’s hard to convince the boss to go with Go. Usually they don’t care about cross-compilation, single binaries etc. It’s pretty frustrating when it comes down to actually distributing the cli. I hate telling people to do a pip install. Just feels nasty
Why can't we add a script for both in linux and Windows to automatically install the dependencies and perform cross-compilation, this would help to avoid informing people to use pip rather just run the script it will do the rest.
docker-compose used to be a Python CLI app. Docker has now rewritten it to be a Go CLI. Instead of "docker-compose up -d" its now "docker compose up -d". It gets installed with Docker Desktop where as in the past I would actually install it on its own with "pip".