MoMo tool isn't very programatically friendly outside python

[amcgee]

The command-line and shell are hard to use programatically, FWIW

[amcgee]

I'd like to change the input/output behavior to be more easier to consume. This article seems like it makes some salient points that we should try to mimic.

To start, we should only open a shell when we explicitly want to (maybe when we pass a -i or --interactive flag).

[timburke]

I'm all for making the momo tool better and I agree with the article
about composability and noninteractiveness.

One point I do want to keep in mind is why I made the tool in the first
place, which is that we have a large API of functions for interacting
with different momo modules and it seemed like it was only going to grow
as we got more modules and more features, so having to write a cmdline
program to gain access to each API feature seemed like it was going to
become untenable and lead to a lot of poorly done command line programs
without good error checking and that would get out of sync with the API.

The things I like about momo are:

• it can take you from playing around to automated python scripts.
  There's a 1-1 map between python calls and momo arguments so if you know
  how to use momo you know how to use the API. You could even automate
  this and record a momo shell session for example and have it spit out a
  script that does that for you automatically that you could edit and use.
• type-safety is handled in the API once and for all. We don't need to
  copy the same path validation logic, number parsing and command flags
  for every tool.
• documentation is contained in the API and the cmdline tools are always
  consistent with the API
• each function in the API is more self-contained. They define what
  types their arguments are, what they're used for and what valid input
  it, which is checked from the cmdline and from python invokations so you
  don't need to repeat lots of error handling code in the API functions
  themselves.
• python functions can return python objects and cmdline invocations can
  print those objects to stdout. One of the struggles with unix tools is
  that, while they are good to combine on the cmdline and in shell
  scripts, they're not amazing to combine programatically and you find
  yourself writing a lot of text parsing in e.g. python to get the data
  you want from the cmdline tool even though you know that before it
  printed it to the console, it probably had it in just the way you wanted
  it, i.e. an array, dict, class, etc. This way you can consume real
  objects from the API if you want to build on it programatically and have
  text output if you want to use it from the cmdline using printers.

That being said, I agree that the tool is not very polished and am all
for polishing it and making sure that it actually achieves useful
objectives in a usable manner. Also down for feedback on the importance
of any of the above points.

• tim

On 10/20/14, 6:53 PM, Austin McGee wrote:

I'd like to change the input/output behavior to be more easier to
consume. This article
http://monkey.org/%7Emarius/unix-tools-hints.html seems like it
makes some salient points that we should try to mimic.

To start, we should only open a shell when we explicitly want to
(maybe when we pass a -i or --interactive flag).

—
Reply to this email directly or view it on GitHub
#124 (comment).

[amcgee]

Yeah absolutely, I like all of those properties. I think one of the main
things is going to be standardizing the way things are printed and making
that machine-consumable.

It's also worth noting that we should figure out what effort would be
required to implement wrappers in other languages and (more importantly) on
different platforms (like android and iOS). It's not dead simple with
python unfortunately...

On Thu Oct 23 2014 at 10:27:35 PM timburke [email protected] wrote:

I'm all for making the momo tool better and I agree with the article
about composability and noninteractiveness.

One point I do want to keep in mind is why I made the tool in the first
place, which is that we have a large API of functions for interacting
with different momo modules and it seemed like it was only going to grow
as we got more modules and more features, so having to write a cmdline
program to gain access to each API feature seemed like it was going to
become untenable and lead to a lot of poorly done command line programs
without good error checking and that would get out of sync with the API.

The things I like about momo are:

• it can take you from playing around to automated python scripts.
  There's a 1-1 map between python calls and momo arguments so if you know
  how to use momo you know how to use the API. You could even automate
  this and record a momo shell session for example and have it spit out a
  script that does that for you automatically that you could edit and use.
• type-safety is handled in the API once and for all. We don't need to
  copy the same path validation logic, number parsing and command flags
  for every tool.
• documentation is contained in the API and the cmdline tools are always
  consistent with the API
• each function in the API is more self-contained. They define what
  types their arguments are, what they're used for and what valid input
  it, which is checked from the cmdline and from python invokations so you
  don't need to repeat lots of error handling code in the API functions
  themselves.
• python functions can return python objects and cmdline invocations can
  print those objects to stdout. One of the struggles with unix tools is
  that, while they are good to combine on the cmdline and in shell
  scripts, they're not amazing to combine programatically and you find
  yourself writing a lot of text parsing in e.g. python to get the data
  you want from the cmdline tool even though you know that before it
  printed it to the console, it probably had it in just the way you wanted
  it, i.e. an array, dict, class, etc. This way you can consume real
  objects from the API if you want to build on it programatically and have
  text output if you want to use it from the cmdline using printers.

That being said, I agree that the tool is not very polished and am all
for polishing it and making sure that it actually achieves useful
objectives in a usable manner. Also down for feedback on the importance
of any of the above points.

• tim

On 10/20/14, 6:53 PM, Austin McGee wrote:

I'd like to change the input/output behavior to be more easier to
consume. This article
http://monkey.org/%7Emarius/unix-tools-hints.html seems like it
makes some salient points that we should try to mimic.

To start, we should only open a shell when we explicitly want to
(maybe when we pass a -i or --interactive flag).

—
Reply to this email directly or view it on GitHub
<
#124 (comment)
.

—
Reply to this email directly or view it on GitHub
#124 (comment)
.

[amcgee]

(bump)

[timburke]

Let's discuss tomorrow.

On 1/26/15 5:10 PM, Austin McGee wrote:

(bump)

—
Reply to this email directly or view it on GitHub
#124 (comment).

[amcgee]

Sounds good

On Mon, Jan 26, 2015, 6:28 PM Tim Burke [email protected] wrote:

Let's discuss tomorrow.

On 1/26/15 5:10 PM, Austin McGee wrote:

(bump)

—
Reply to this email directly or view it on GitHub
<
#124 (comment)
.

—
Reply to this email directly or view it on GitHub
#124 (comment)
.