Don't write command-line interfaces (and how to write if you have to) • Hacker News Board

Re: Don't write command-line interfaces (and how to write if you have to)

#21

Post by olejorgenb » Sat, Oct 10, 2020, 11:05 AM UTC

I read the core argument as:

Don't write a shell CLI prematurely - a script in whatever language you're using can often be just as good a interface. Maintaining a shell CLI is work.

If you write a shell CLI don't aim for full flexibility - a script already fulfill that role.

I'm a big fan of shell CLIs (command --option=1), but I think this way of thinking has merit. I would consider a script a subset of CLIs though, using a python REPL with preloaded modules is certainly a type of CLI, no? Code is a sequence of commands.

That being said, as the author mentions, new libaries make it really easy to expose some functions to a shell CLI. If the task mesh well with piping, exposing some primitive to the shell is probably worth it.

Re: Don't write command-line interfaces (and how to write if you have to)

#22

Post by arogozhnikov » Sat, Oct 10, 2020, 6:40 PM UTC

ceceron wrote: post #20

arogozhnikov wrote: post #15

Earlier quoted context omitted.

> Agree the CLI "shell" around the system should not have separate logic that was the main point. > should report back logic faults from within the library And I suggest validating parameters passed to functions. So what's this you disagree with?

I share @ezekiel68 feeling. Your solution to replace CLI parameters with code is a terrible idea... 1) CLI support is an additional logic in your program that makes no real work CLI is a user interface, it does real work as giving user way to interact with your program. It's an interface. 2) Error (exception) handling with CLI is very poor. Another layer of (bad faulty) code is required to make it possible. Like with…

> API != User Interface. API = Programming Interface.

That's where we should start, but the other way around. Why do you keep trying to replace programming interfaces with bash calls?

Any example when calling cli compared to proposed alternative makes any difference to your spouse?

Re: Don't write command-line interfaces (and how to write if you have to)

#23

Post by arogozhnikov » Sat, Oct 10, 2020, 6:41 PM UTC

olejorgenb wrote: post #21

I read the core argument as: Don't write a shell CLI prematurely - a script in whatever language you're using can often be just as good a interface. Maintaining a shell CLI is work. If you write a shell CLI don't aim for full flexibility - a script already fulfill that role. I'm a big fan of shell CLIs (command --option=1), but I think this way of thinking has merit. I would consider a script a subset of CLIs though,…

sums it up pretty well

Re: Don't write command-line interfaces (and how to write if you have to)

#24

Post by xtiansimon » Tue, Oct 13, 2020, 7:14 PM UTC

ezekiel68 wrote: post #3

Strong disagree. Any system worth keeping around should be a library (or family of libraries) which have a CLI fronting it that serves to pass parameters to it just as you might any other way (such as through some other program or REST API or GUI). Agree the CLI "shell" around the system should not have separate logic, but should report back logic faults from within the library.

> "Any system worth keeping around should be a library (or family of libraries)..."

I'm interested to read more about this topic.

I maintain about 8-10 Python Click CLI scripts (a la 'Practical Business Python') which are basically clones of 2-3 original scripts. These have worked really well for me (developing them) and for the handful of colleagues who I share them with.

This summer I started a project to put a Flask front end on a few of the CLI scripts.

Reading the OP I started to imagine the decorator-on-function from `typer` might be an interesting way to maintain functions for the Flask App to call and still preserve the CLI functionality.

Then again, and I'm a neophyte here, I assume a 'library' formalization would give me both options as well...

Re: Don't write command-line interfaces (and how to write if you have to)

#25

Post by ceceron » Thu, Oct 15, 2020, 7:49 AM UTC

arogozhnikov wrote: post #22

ceceron wrote: post #20

Earlier quoted context omitted.

I share @ezekiel68 feeling. Your solution to replace CLI parameters with code is a terrible idea... 1) CLI support is an additional logic in your program that makes no real work CLI is a user interface, it does real work as giving user way to interact with your program. It's an interface. 2) Error (exception) handling with CLI is very poor. Another layer of (bad faulty) code is required to make it possible. Like with…

> API != User Interface. API = Programming Interface. That's where we should start, but the other way around. Why do you keep trying to replace programming interfaces with bash calls? Any example when calling cli compared to proposed alternative makes any difference to your spouse?

Mostly because user interface is meant to expose the common tasks to the user vs API which is supposed to give a low level control. curl is a good example, as a tool is fairly accessible, but as the library it gives control on all the aspects of connection, requiring much more knowledge/skill from the programmer. Not every user has this kind of knowledge, but still may want to use curl to do quick HTTP requests.

User != Programmer

Also, "bash calls" are cool - shell is a great tool to compose many diverse tools written in different programming languages. If all the tools were just configurable via writing code in their implementation language: 1) you would have to know all the programming languages 2) you would have to somehow input the code, parameters are just shorter than code