Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oq: Terminal OpenAPI Spec Viewer

github.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Oq: Terminal OpenAPI Spec Viewer

#11

Post by der_gopher »

barryoneill wrote: post #10

Nice! Just a quick heads up that there's already an 'oq' project https://blacksmoke16.github.io/oq/ | https://github.com/Blacksmoke16/oq (as I discovered when I installed oq via homebrew to find myself with a different app)

Yeah, the name is very short to be unique. I don't want to rename yet, as I am ok if there are other projects with the same name as long as there is no legal trademark or something. But yeah, don't install it from the Homebrew, btw I added binaries to releases page so we can just wget it.

Re: Oq: Terminal OpenAPI Spec Viewer

#12

Post by mdaniel »

der_gopher wrote: post #11
barryoneill wrote: post #10

Nice! Just a quick heads up that there's already an 'oq' project https://blacksmoke16.github.io/oq/ | https://github.com/Blacksmoke16/oq (as I discovered when I installed oq via homebrew to find myself with a different app)

Yeah, the name is very short to be unique. I don't want to rename yet, as I am ok if there are other projects with the same name as long as there is no legal trademark or something. But yeah, don't install it from the Homebrew, btw I added binaries to releases page so we can just wget it.

Two things: folks care about Brew because its update story is nice; otherwise one needs to constantly revisit your /releases (or plug /releases.atom into their RSS reader) in order to know. It also offers very light "I got what I expected" behavior via their use of sha256, which your current setup won't participate in since you're only publishing .md5 anyway

That leads to the second thing which is that you said you "added binaries" but your release artifacts are .tar.gz which means that one now needs to `curl -fSL | tar -xzf - -C /whatever` and deal with whatever interior directory scheme you are using (I didn't check)

I suspect I may be throwing good commentary after bad, but if you did want to participate in Brew distribution, but don't want to go through their stupid PR process, you can retain control over your update schedule by creating a "Brew Tap" and then the consumer would (e.g.) `brew tap plutov/brew && brew install plutov/brew/oq` which also gets away from the naming collision

Re: Oq: Terminal OpenAPI Spec Viewer

#13

Post by der_gopher »

mdaniel wrote: post #12
der_gopher wrote: post #11

Earlier quoted context omitted.

Yeah, the name is very short to be unique. I don't want to rename yet, as I am ok if there are other projects with the same name as long as there is no legal trademark or something. But yeah, don't install it from the Homebrew, btw I added binaries to releases page so we can just wget it.

Two things: folks care about Brew because its update story is nice; otherwise one needs to constantly revisit your /releases (or plug /releases.atom into their RSS reader) in order to know. It also offers very light "I got what I expected" behavior via their use of sha256, which your current setup won't participate in since you're only publishing .md5 anyway That leads to the second thing which is that you said you "…

I also love Homebrew and use it daily, at the same time I don't want to go through the review process, but tap sounds good, will try it out, maybe goreleaser supports that too?

Re: Oq: Terminal OpenAPI Spec Viewer

#15

Post by thegagne »

RadiozRadioz wrote: post #5

Nice, I'll find this useful. I reference OpenAPI specs frequently as I practice spec-driven development. The spec is my source of truth for the interface, and I use it to generate both my client and server code. It automates all the request handling boilerplate on both sides, including validation, and provides me a typed interface regardless of which language I'm using. OpenAPI of course limits the types of endpoints…

What’s in your toolkit for server and client generation?

Re: Oq: Terminal OpenAPI Spec Viewer

#16

Post by thegagne »

oulipo2 wrote: post #3

Really cool! would be cool to be able to do the actual call too :)

Check out https://aep.dev, they have a CLI tool for doing that, _if_ you write your OpenAPI to follow their spec. We are adopting it, both because of the nice standard it provides and also for the guaranteed tooling (TF, MCP, CLI).

Re: Oq: Terminal OpenAPI Spec Viewer

#17

Post by RadiozRadioz »

thegagne wrote: post #15
RadiozRadioz wrote: post #5

Nice, I'll find this useful. I reference OpenAPI specs frequently as I practice spec-driven development. The spec is my source of truth for the interface, and I use it to generate both my client and server code. It automates all the request handling boilerplate on both sides, including validation, and provides me a typed interface regardless of which language I'm using. OpenAPI of course limits the types of endpoints…

What’s in your toolkit for server and client generation?

My servers are Java, my clients are Python. I use the Spring & Python generators in https://github.com/swagger-api/swagger-codegen

Re: Oq: Terminal OpenAPI Spec Viewer

#18

Post by deltaknight »

der_gopher wrote: post #13
mdaniel wrote: post #12

Earlier quoted context omitted.

Two things: folks care about Brew because its update story is nice; otherwise one needs to constantly revisit your /releases (or plug /releases.atom into their RSS reader) in order to know. It also offers very light "I got what I expected" behavior via their use of sha256, which your current setup won't participate in since you're only publishing .md5 anyway That leads to the second thing which is that you said you "…

I also love Homebrew and use it daily, at the same time I don't want to go through the review process, but tap sounds good, will try it out, maybe goreleaser supports that too?

Honestly whilst the docs make the review process sound complicated, I went through it a few months ago and it ended up being super simple. Just follow the instructions to create the new formulae PR (and look at other recent ones) and then you’re all done. Updates are handled by a bot they run automatically when you make a new GitHub release, so you don’t even need to interact with the homebrew repo after setup.

You do have a naming conflict though unfortunately so I’m not sure how you would deal with that.

Post reply on HN