CF CLI in Go

[Matthew Kocher]

We've encountered quite a bit of pain from users installing a ruby interpreter just to use the cf gem.  One of the big benefits of go is that it produces relatively small statically linked binaries that don't depend on any shared libraries - so installation is just downloading a single file.  We also were encountering increasing pain modifying the cf codebase, as it wasn't test driven and is difficult to write tests around, and were looking at a big effort to refactor the ruby codebase.

A few weeks ago we started trying out a new CLI written in Go.  After two weeks we're happy with the progress and will be continuing with the project.

The repo is available here: https://github.com/cloudfoundry/cli and you will shortly be able to download the current binaries from the releases tab on github.

This is an early work in progress which you're welcome to try out, but realize that it's not yet a replacement for the cf gem.  In the long run, we expect the go cli to eclipse the cf gem, but we are quite a ways from that point.  For the foreseeable future we expect to keep supporting the cf gem and merging pull requests.

[Dr Nic Williams]

Having done several workshops/demos, it is surreal how awkward the "oh ok; let's all now learn how to install ruby for the next hour" hour is. A cf (and I guess bosh) CLI as a stand-alone executable is a "good thing" for humans. Thanks for progressing with with!

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Matt Reider]

Exactly.

Ruby, Rbenv, RVM, native libraries, compilers, etc. none of this needs to be contemplated when it comes to installing the keys to the Cloud Foundry kingdom. It should just work.

Sent from my iPhone

[Mike Youngstrom]

I don't know much about Go and how it works library and linker wise.  Will it be possible to have a plugin mechanism with the Go CLI like we have today with the Ruby one?

Mike

[Matt Reider]

There's no plugin architecture like Ruby. I guess you could say this is a downside, but recompiling with a new component doesn't seem like too high of a cost, and you could provide tools to do that quickly. The other way is to have a separate process running like any command line tool, maybe provide the means for integration that don't require piping output and such.

There is a project called go-eval that would solve for all of this, but it needs to evolve.

Sent from my iPhone

[Scott Truitt]

This is something the team is aware of and actively discussing. Will post with more details soon. 

[Arthur Maltson]

Just curious, isn't it possible to build a binary using Ruby? Thinks like ocra (https://github.com/larsch/ocra) and fpm (https://github.com/jordansissel/fpm) seem to be capable of building binaries.

Actually had another question with regards to clients (maybe worth another thread), are there any plans on enabling git based deploys to CF? I understand service enabling might be easier with a cli, but it does get all declares in the deployment yaml file AFAIR. 

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

--

Arthur Maltson

[Matt Reider]

Yes there are tools to create executables. We use them to create our current cf windows .exe. the trade off, in my opinion, is that each platform has a different set of tools, maintained by different people, with different limitations.

Github deploys. We have talked about it. It's definitely a roadmap item.

Sent from my iPhone

[mike....@gmail.com]

Mike, it is possible to build a plugin mechanism in Go.

Packer (http://www.packer.io/docs/extend/plugins.html) has one and we are talking about spending some time to figure out how it works and how we could utilize with the Go CLI tool.

[Doug Davis]

+1  Regardless of which language it is written in, a stand-alone exe would be really nice.  Having to install one language to develop an app in another is odd from a usability perspective.

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.

"Dr Nic Williams" ---09/06/2013 11:58:00 PM---Having done several workshops/demos, it is surreal how awkward the "oh ok; let's all now learn how t

[Dr Nic Williams]

Can I ask the repo be changed from "cli" to "cf-cli" or similar. Currently if anyone forks the project the name will not have any meaning attached to it - drnic/cli is the CLI for what?

On Sun, Sep 8, 2013 at 10:24 AM, Doug Davis <d...@us.ibm.com> wrote:

+1  Regardless of which language it is written in, a stand-alone exe would be really nice.  Having to install one language to develop an app in another is odd from a usability perspective.

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.

<graycol.gif>

[Tammer Saleh]

I'm pretty sure you can now rename a fork in github (since they started redirecting for you). There are a lot of project/vague_component_name repos out there, so I generally just rename my long running forks to reduce confusion.

Cheers,

Tammer Saleh

[Scott Truitt]

In the interest of building the simplest thing that will work, we're going to forgo a plugin architecture. 

If there's something you want to see in the new cli, please fork the repo and submit a PR. To give you a better sense of where we're going next, we're also working on exposing our backlog on http://cftracker.cfapps.io/  

Thanks,

Scott

[Dr Nic Williams]

Scott, I think a plugin architecture - the ability for the vast ecosystem to plugin/reuse code and connections - is important. More important than simplicity if the two need to be compared and valued.

Perhaps the go re-write isn't something we should do if it means a step backwards in our goals of a pluggable CF platform?

[Scott Truitt]

Understood. We haven't ruled it out, we're just not ready to prioritize it today. 

[api...@gopivotal.com]

A CLI for drnic would be really helpful....

(I'll get my coat)

On Sunday, September 8, 2013 6:42:50 PM UTC+1, Dr Nic Williams wrote:

Can I ask the repo be changed from "cli" to "cf-cli" or similar. Currently if anyone forks the project the name will not have any meaning attached to it - drnic/cli is the CLI for what?

On Sun, Sep 8, 2013 at 10:24 AM, Doug Davis <d...@us.ibm.com> wrote:

+1  Regardless of which language it is written in, a stand-alone exe would be really nice.  Having to install one language to develop an app in another is odd from a usability perspective.

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.

<graycol.gif>

"Dr Nic Williams" ---09/06/2013 11:58:00 PM---Having done several workshops/demos, it is surreal how awkward the "oh ok; let's all now learn how t

From: "Dr Nic Williams" <drnicw...@gmail.com>
To: vcap...@cloudfoundry.org,
Cc: vcap...@cloudfoundry.org
Date: 09/06/2013 11:58 PM
Subject: Re: [vcap-dev] CF CLI in Go

---

Having done several workshops/demos, it is surreal how awkward the "oh ok; let's all now learn how to install ruby for the next hour" hour is. A cf (and I guess bosh) CLI as a stand-alone executable is a "good thing" for humans. Thanks for progressing with with!

[Dr Nic Williams]

I'd need to first respond to API calls in a timely, deterministic fashion :)

[Patrick Mueller]

It seems like a plugin architecture for Go will have to be via external programs - we don't want folks to have to recompile the cf command to add a plugin.  Git supports this somehow by executing "git-foo ..." when you run "git foo ...".  Not sure exactly how it works.

What would make this nicer is if you could get JSON output out of a cf command.  You could write a new subcommand by scripting the input/output of other cf commands.

The general idea is to make cf both a command-line tool AND a library, kinda like git - http://git-scm.com/book/ch9-1.html 

--
Patrick Mueller
http://muellerware.org

[Dr Nic Williams]

The CLI-that-can-call-other-CLIs (say external but in $PATH) and the shared library sound like a good solution. Thanks mate.

[Manuel Garcia]

Nice work.

Besides being a great 'no dependencies' approach,  it perform incredibly better (same account/org/space):

$ time go-cf apps

Getting applications in Development

OK

name           status    usage       url                                

….

10 apps

…

real 0m0.580s

$ time cf apps

Getting applications in Development... OK

name           status    usage      url                             

….

10 apps

…

real 0m2.596s

- Manuel Garcia

[Patrick Mueller]

Just to be clear, the traditional concept of a "shared library" (eg, DLL on Windows), is something you can't really do with Go, nor is it something (assuming the shared library had a C interface) that could be used by Go easily, nor would it be easily consumable from most scripting languages (would need to use a Foreign Function Interface).

It'd be a "shared library" in the sense of the unix philosophy of "small programs that do one thing", although in this case they'd be "small subcommands that do one thing" and "they spit out JSON".

[Dr Nic Williams]

I was hoping for library of API helpers, structs etc that plugins/other CLIs could use so not to have to rewrite everything.

[Patrick Mueller]

Ya, so I was thinking that can just be the commands we use with cf today, except instead of printing colorful output to my ascii terminal, they'd write JSON to stdout.

eg:

    cf --json apps

stdout:

    {

        "status": "ok",

        "result": [

            {

                "name": "my-app-A",

                "status": "running",

                "instances": 1,

                "url":  "my-app-A.cfapps.io",

                ...

            },

            {

                ...

            }

        ]

    }

It would make the most sense to just spit out the same JSON that came from the cf servers, that way you don't have to describe JSON structures for HTTP usage vs JSON structures for cf command usage.

And of course you have `cf --json curl` in a pinch ...

And then you can write "scripts" that invoke these commands, and get the output.

[David Laing]

+1 for git style integration hook scripts - I've just added them to the .net-buildpack -> https://github.com/cloudfoundry-community/.net-buildpack/issues/15, and its surprisingly useful because you can extend using the best language for the situation.

--
David Laing
Open source @ City Index - github.com/cityindex
http://davidlaing.com
Twitter: @davidlaing