Deploy membrane.term to clojars

[phronmophobic]

@lread

I'm going to publish membrane.term to clojars. I'll probably start with version 0.9, but I'd like to bump to "1.0" pretty soon since we're already at a decent base level of functionality.

I think the only step before flipping to 1.0 is to review all the public vars/functions and see if there's any changes we might want to make.

Anything else I might be missing?

[lread]

One thing I'm struggling a bit with is command-line shortops.

We'll soon have --font-family so -f? Oh but that's used already for --final-delay.

And --color-scheme... -c? But we'll likely have --command soon, so maybe -s? Oh but we'll soon have --font-size which might use -s.

So... maybe I'll turf the short options? Watcha think? Be annoying, even maybe dangerous, for folks if we changed them on them.

[lread]

Oh and I guess pty4j being in a JetBrains maven repo is slightly annoying but addressable by docs. And maybe a fix is imminent?

[phronmophobic]

Are two letter short options like -ff available?

When I was thinking about the delay args, I was wondering if it might make sense to group them as --delay-final, -df, and --delay-line, -dl.

But that is a good point. We may want to sort out the command line args before v1

[lread]

I'd probably also add a Status section to the docs. Just to remind folks this membrane.term is in early stages and things is subject to change. Not sure if you want to label it alpha, up to you.

[lread]

Oh and maybe mark your mark the API with ^:no-doc where appropriate so that cljdoc doesn't document private things.

[lread]

When I was thinking about the delay args, I was wondering if it might make sense to group them as --delay-final, -df, and --delay-line, -dl.

This excellent idea was just tried by yours truly. Docopt does not support it, it is designed to see, perhaps reasonably so, -df as two options -d -f.

[phronmophobic]

I'd probably also add a Status section to the docs. Just to remind folks this membrane.term is in early stages and things is subject to change. Not sure if you want to label it alpha, up to you.

I don't think it's worth going to 1.0 if we don't think the API is stable. It adds quite a bit of value to try to provide a stable API. I don't think there's any reason we couldn't decide on a stable API, but it does seem like it's worth waiting until all of the already planned/in-progress changes are done.

[phronmophobic]

This excellent idea was just tried by yours truly. Docopt does not support it, it is designed to see, perhaps reasonably so, -df as two options -d -f.

Welp, I don't have any other ideas off the top of my head.

[lread]

Maybe I'm the wrong guy to ask though. I've had rewrite-clj v1 in alpha for maybe too long. 🙂

You can always release 1.0.0-alpha though. Always nice to get feedback.

Oh and you'd have to decide on a versioning scheme I suppose (if you don't already have a favorite).

[phronmophobic]

Maybe I'm the wrong guy to ask though. I've had rewrite-clj v1 in alpha for maybe too long. 🙂

Membrane has been in 0.9.*-beta since forever and will likely remain that way for a while. I'm still working towards 1.0, but the different with membrane.term is that it seems like the scope is smaller and I can more reasonably commit to a useful, stable API.

Oh and you'd have to decide on a versioning scheme I suppose (if you don't already have a favorite).

I don't. I was hoping you had some good thoughts on that :p.

[lread]

I did a little thinking on versioning for rewrite-clj.

All very subjective. The commit count seems to be popular these days. I like it because it manages itself and I don't have to think about it. But frankly, 1.0.699-alpha is harder to remember than say 1.0.12-alpha. The old-fashioned simple increment by one strategy is a good choice too.

[lread]

So I'm looking at various unix commands... ls seems to have shortopts for almost every letter of the alphabet in uppercase and lowercase! I think they got to a point where they just picked a letter. Doesn't seem to use longopts at all.

The bash shell has some longopts without shortops. For less frequently used opts this might make sense?

The more modern tool ripgrep, has many longopts without equivalent shortops.

[lread]

One other strategy is to stick with keywords for opts on the command line. This is the strategy taken by api-diff. Ex:

clj -M:api-diff :lib zprint/zprint :v1 0.4.16 :v2 1.1.2 :exclude-meta no-doc

Folks will not expect shortopts for keywords. But if the tool is to be adopted outside the Clojure community, the keyword notation will seem odd.

[phronmophobic]

Of the different proposals so far, I like just omitting some short ops for less commonly used args.

[lread]

Of the different proposals so far, I like just omitting some short ops for less commonly used args.

Sounds good, here's my WIP:

Common Options:
  -w, --width=<cols>         Width in characters [default: 90]
  -h, --height=<rows>        Height in characters [default: 30]
  -c, --color-scheme=<path>  Local path or url to iTerm .itermcolors scheme file, uses internal scheme by default.
  -f, --font-family=<font>   Choose an OS installed font [default: monospace]
  -s, --font-size=<points>   Specify the font point size [default: 12]

Screenshot Options:
  -p, --play=<path>          Path to script to play in terminal
  -o, --out=<file>           Filename of the image to generate [default: terminal.png]
  -l, --line-delay=<ms>      Delay in ms to wait after each line is sent to the terminal [default: 1000]
  -d, --final-delay=<ms>     Delay in ms to wait before writing the view of the terminal [default: 10000]

Could become maybe:

Common Options:
  -w, --width=<cols>         Width in characters [default: 90]
  -h, --height=<rows>        Height in characters [default: 30]
      --color-scheme=<path>  Local path or url to iTerm .itermcolors scheme file, uses internal scheme by default.
      --font-family=<font>   Choose an OS installed font [default: monospace]
      --font-size=<points>   Specify the font point size [default: 12]

Screenshot Options:
  -p, --play=<path>          Path to script to play in terminal
  -o, --out=<file>           Filename of the image to generate [default: terminal.png]
      --line-delay=<ms>      Delay in ms to wait after each line is sent to the terminal [default: 1000]
      --final-delay=<ms>     Delay in ms to wait before writing the view of the terminal [default: 10000]

[lread]

README will always show long opts because they describe things better.

[phronmophobic]

Looks great!

[lread]

Oh and of course you'll need a Slack chat channel. I'd join!

[lread]

Oh yeah: you also reference your fork of vt via :git/url. So you'll need to either include those sources into your jar or publish your vt fork to clojars. I remember (the now deprecated) depstar supporting including :git/url dependencies in a target jar, not sure what tools build does.

But: If you do include forked vt sources in membrane.term, it can be considered unexpected, confusing and problematic for folks who may also innocently depend upon asciinema/vt.

[phronmophobic]

But: If you do include forked vt sources in membrane.term, it can be considered unexpected, confusing and problematic for folks who may also innocently depend upon asciinema/vt.

Seems unlikely since I don't think asciinema/vt is on clojars or maven. Either way, it probably makes sense to also deploy vt to clojars as well. What's the right way to name it? com.phronemophobic.asciinema/vt?

[lread]

What's the right way to name it? com.phronemophobic.asciinema/vt?

Good question. Dunno. I think folks typically leave out the source group id?

Also: I'm gonna assume you are all good with clojars and the new-ish verified group names requirements.

[phronmophobic]

Ok, I'll go with com.phronemophobic/vt

Yep, com.phronemophobic is a verified group for me.

[phronmophobic]

Deployed! https://clojars.org/com.phronemophobic/membrane.term