Consistently use .snet directory inside a project for all SNet stuff.

[ferrouswheel]

Splitting up the proposal from #104 into specific suggestions.

Local state

Instead of tracking config related to snet-cli globally, and dumping different config json files in different locations, we should keep all SNet related files together.

e.g. inside a service directory, we could have a structure like:

• .snet\service.json
• .snet\daemon.json
• .snet\docs\* - documentation to be bundled into an archive and uploaded to IPFS #176
• .snet\lib\* - compiled protobuf files could go here too as part of the SDK. We don't want to pollute a project's path, so protobuf files compiled for external services can be kept isolated from the files a developer is actually working on.
• .snet\[other?]

The daemon and CLI could then read the information they need from this local context if it exists.

Motivation:

• the daemon wouldn't require a user to specify where the config file is, and the user wouldn't have to separately create it. All this information could be generated as part of creating a service.
• the current_* state variables are not a useful pattern to service authors. It's hard to remember what the current identity, network, etc are set to. All of these could be stored in service.json meaning the user doesn't have to remember anything... they just have to be in the right directory.

In addition, like git, if there is no .snet directory, our tools should walk to parent directories until a .snet directory is found and use that.

[ferrouswheel]

I think there are three different classes of data that need to be stored:

• data that is used to publish a service - .snet\service.json, .snet\daemon.json, .snet\docs\* etc.
• data that is used by an application to depend on SNet services and build and deploy the application. This application may or may not be an SNet service itself. - e.g. compiled protobuf, possibly preinitialised channel id, etc.
• data that is used by an application at run time - e.g. channel state

I think we should be able to keep all of these somewhat separate. If I'm testing an application that uses SNet services, I don't want the channel state deployed, but I do want the compiled protobuf deployed (at least for dynamic languages like python, C++ etc would compile them into the executable)

[astroseger]

@ferrouswheel
In https://github.com/singnet/snet-sdk-python/issues/9 you proposed to store all information in "project" directories as git does. It is ok for service providers but not for clients. How it will work on the client side?

[ferrouswheel]

@astroseger We should differentiate between clients:

• Application developer using SDK and CLI - should use a project directory related to their application that depends on SNet services (use .snet)
• Service developer using CLI to publish service and make test client calls (use .snet)
• One off client call for playing around or doing simple integrations - use ~/.snet-default

We should distinguish between the first two and the last one intelligently. One way would be:

• walk parent directories until a .snet directory is found
• if a directory is found use it
• if a directory is not found, use ~/.snet-default

I'm not 100% about exactly what should go in the home directory vs the project directory. So possibly we should outline the directory structure for each use case. I also would want the daemon to automatically configure itself using a project's .snet directory.

[astroseger]

@raamb We need to define user stories and based on them think about general architecture to solve this and several other issues https://github.com/singnet/snet-cli/issues/174 https://github.com/singnet/snet-cli/issues/175 #176 https://github.com/singnet/snet-cli/issues/181 (plus unification with SDK https://github.com/singnet/snet-sdk-python/issues/9)

There are, at least two possible approaches:

• relay on local copy of files (like in git as @ferrouswheel propose).
• relay only on information from blockchain/IPFS and consider local copy only as cache. Which is implemented in the current version (in this case it doesn't matter there your cache is stored...).

We should select one approach and consistently follow it.

[raamb]

@astroseger I think @ferrouswheel is also treating the local copy as cache from blockchain and IPFS but is suggesting that we store it at a service level instead of at a global level (user home). @ferrouswheel please correct if I got it wrong.

[ferrouswheel]

Yes I think the .snet dir should be at the service level, but rather than a cache, I'm thinking that the local copy is the canonical version and should be pushed to the blockchain/ipfs when developers have made changes.

This is more in line with how other platforms-as-a-service work, like zeit.co, heroku and others. Developers are used to pushing their local changes into production...not syncing with a remote data source and updating it.

Kubernetes kind of do this sync/update cycle, but it's quite painful and people have had to build systems to work around it.

On Mon, 1 Apr 2019, 7:52 PM raamb, [email protected] wrote:

@astroseger https://github.com/astroseger I think @ferrouswheel https://github.com/ferrouswheel is also treating the local copy as cache from blockchain and IPFS but is suggesting that we store it at a service level instead of at a global level (user home). @ferrouswheel https://github.com/ferrouswheel please correct if I got it wrong.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/singnet/snet-cli/issues/173#issuecomment-478457663, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHWB58aYUI6zapCLO4bjWEKWr-i3b03ks5vcay9gaJpZM4aJzYz .

[astroseger]

Ok... Actually I don't see much difference, it doesn't matter what we consider the "canonical" version. We can easilly support both points of view.

We simply should have two "commands":

• "update_from_ipfs_blockchain"
• "push_to_ipfs_blockchain"

Bold service providers who consider their local copy as "canonical" will never use "update_from_ipfs_blockchain".

I agree that we could have a default directory in which a service provider store his stuff (metadata, proto files, documentation etc... )