cnabio / cnab-rs Goto Github PK

Per the community meeting, we should begin cutting versioned releases and putting them in crates.io

Dependent crates will end up with usages like this:

use libcnab::cnab::Bundle;

All the interesting exports are also currently hidden behind the cnab module in the generated cargo doc. Perhaps it would be more ergonomic to move everything currently in cnab.rs to lib.rs, or re-export everything from lib?

The latter is possible by changing the use statement in lib.rs:

mod cnab;
pub use crate::cnab::*;

I think the latter option is relatively idiomatic, and keeping lib reserved for mostly doc comments is nice.

Crate names should not use -rs or -rust as a suffix or prefix. Every crate is Rust! It serves no purpose to remind users of this constantly.

Coming from the Rust Language Nursery Documentation.

Should we rename this crate to simply libcnab?

Per the community meeting today, we decided to rename this library to follow the common conventions.

This ONLY involves renaming the repo

I don't know much about rust, how do I build this thang?

We should represent the JSON Schema using a structured type instead of serde_json.Value, but that likely entails finding the right crate.

• created is required cnabio/cnab-spec#295
• bundleReference is added cnabio/cnab-spec#299
• Claims must be mounted at /cnab/claim.json cnabio/cnab-spec#300
• CNAB_CLAIMS_VERSION must be set in the invocation image

We should run tests on master and PRs.

Hi team,
thank you for starting the work on the rust implementation.

Is there any plan to develop the rust-implementation further? ( or in general if there is any contribution document or features being developed currently etc. which can be followed )

We should update the readme with the steps required and examples for using this library, as well as for building and contributing.

As discussed here, I think we're all having some mixed feelings about Spectral as the library we want to use for assertion testing. It can be a little verbose in lieu of simpler assertions (like the core assert!/assert_eq! macros). Now might be a good time to decide.

/cc @jlegrone and @glyn

This allows zero-copy json parsing, at the cost of complexifying the lifetime handling, and not being able to parse from a stream (as the json string from which the string slices are borrowed must outlive the deserialized structure), thus making Bundle::from_file currently not buildable.

I guess we must choose either to

• support loading from a stream (thus making the Bundle and substructures own their strings)
• only support the from_string with constraints on the source string lifetime.

We'd like to get this project operating a little more smoothly, getting it toward a release-quality library (instead of a highly experimental one as it is today).

@jlegrone and @glyn: Are you too interested in helping with the ongoing core maintainership of this repo?