singnet / snet-cli

SingularityNET CLI for interacting with SNET blockchain contracts and deployed services.
MIT License
77 stars 53 forks source link

Shorten service sub-commands #177

Open ferrouswheel opened 5 years ago

ferrouswheel commented 5 years ago
    metadata-init       Init metadata file with providing protobuf directory
                        (which we publish in IPFS) and display_name
                        (optionally encoding, service_type and
                        payment_expiration_threshold)
    metadata-set-fixed-price
                        Set pricing model as fixed price for all methods
    metadata-add-group  Add new group of replicas
    metadata-add-endpoints
                        Add endpoints to the groups
    metadata-add-description
                        Add service description
    publish-in-ipfs     Publish metadata only in IPFS, without publising in
                        Registry
    publish             Publish service with given metadata
    update-metadata     Publish metadata in IPFS and update existed service
    update-add-tags     Add tags to existed service registration
    update-remove-tags  Remove tags from existed service registration
astroseger commented 5 years ago

I agree that snet service commands are rather long and we probably should do something with it.

But it will be really confusing to simply remove metadata- and update- prefix (we would have, for example, add-tags and add-group with very similar name but with very different semantic.)

metadata- prefix shows that this function is working with metadata locally! update- - prefix indicate that we make real update of data in registry.

We could simply make separate set of commands snet service-metadata and move all metadata related function there....

ferrouswheel commented 5 years ago

Good point about add-tag and add-group.

I think putting things that work on the local file under snet service-metadata or just snet metadata would be good. It wasn't clear to me that all metadata- prefix meant working with a local file. But I see that pattern now! If it was it's own command it could have a explanation in the --help explaining that these all just modify a local file until you publish/update.

I feel like publish-in-ipfs, publish, update-metadata are all variants of publish and should be controlled by a single publish/push command that either has subcommands or flags to choose what to publish or whether to force it to create a new service rather than update an existing one.