Can't get it to start on macOS using `container`

[benthillerkus]

Assuming container is installed:

1. Create Dockerfile & registry.json like in Tutorial

FROM ghcr.io/sourcemeta/registry:3.2
COPY registry.json .
COPY schemas schemas
RUN sourcemeta registry.json

{
  "url": "http://localhost:8000",
  "html": {
    "name": "my name"
  },
  "contents": {
    "my-first-schema": {
      "title": "Hard to come up with a title",
      "description": "sorry",
      "path": "./schemas"
    }
  }
}

And some valid json schema inside of ./schemas

2. Run container build --tag smr --file Dockerfile .
3. The image should be build. If the schema in ./schemas is invalid, building will fail
4. Try running the container container run smr

❯ container run smr
Error: internalError: "Failed to change directory to '/source' Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory""

When changing the Dockerfile like this:

- RUN sourcemeta registry.json

Running will produce this output:

❯ container run smr                            
Sourcemeta Registry v3.2.0 Starter Edition
unexpected error: filesystem error: cannot make canonical path: No such file or directory [/sourcemeta]

[jviotti]

Hey @benthillerkus ,

Thanks for reporting this. Interesting. I never tested this with container. Just to confirm, does it work fine for you with plain official Docker?

I'm on the go right now but I'll see if I can reproduce and fix tomorrow. Maybe we could add container-based tests to CI too

[benthillerkus]

@jviotti After filing the issue, I tried it with Orbstack which worked

[jviotti]

Nice to hear that @benthillerkus ! Let me still fiddle with container and see if I can make it work and document it on the site.

Also, I'm actively building this Registry, so really looking forward to any feature requests, bug reports, or ideas!

[benthillerkus]

Also, I'm actively building this Registry, so really looking forward to any feature requests, bug reports, or ideas!

The feature I was looking for was human readable documentation mostly. So kinda like the docusaurus plugin. As of right now the registry just renders the schema in plain text as far as I can tell?

[jviotti]

@benthillerkus It is on the roadmap, but not there yet. We want the documentation generation to cover also non-trivial schemas with recursion, dynamic references, etc so the whole approach to generating proper documentation can definitely be tricky! That said, stay tuned, as we have some of the logic behind it ready. For example, we predict instance locations on arbitrarily complex schemas to derive docs for it.

What is the Docusaurus plugin you are referring to btw? Would love to take a look for inspiration

[jviotti]

On container, if the Dockerfile does any operation on /source, then it magically all works, i.e.:

FROM ghcr.io/sourcemeta/registry:3.2
COPY registry.json .
COPY schemas schemas
RUN sourcemeta registry.json
# This makes it work?
RUN ls -l /source

Given that container is considered a bit alpha and that Orbstack (and Docker) works, then maybe this is a bug on container. I'll keep it open for a while and try again in the future. I guess later on it should just work out of the box?

[benthillerkus]

What is the Docusaurus plugin you are referring to btw?

https://github.com/jy95/docusaurus-json-schema-plugin

Though from what I've seen the most impressive tooling in this space is https://github.com/MetaConfigurator/meta-configurator

Because you asked, here are some general things I noticed when trying out a bunch of these doc generators:

• Some missed features like "readOnly" / "writeOnly" -> Even if there's no special styling I think every unknown attribute on the schema should be displayed in the documentation
• Some didn't display "examples"
• Those that heavily used twirling to open sub-objects quickly became very cumbersome to read and often had CSS with too much padding, resulting in lots of scrolling. Leaf objects should probably be visually inlined somehow and there should probably be some display option that focusses just on the fields and their names and hides the rest to make implementation easier.