search

bcgov / von-network

A portable development level Indy Node network.
Apache License 2.0
163 stars 188 forks source link

Indy SDK Raw Build? #8

Closed benjsmi closed 6 years ago

benjsmi commented 6 years ago

https://github.com/bcgov/von-network/blob/master/Dockerfile#L61-L66, which is:

# Build libindy
RUN git clone https://github.com/hyperledger/indy-sdk.git
WORKDIR /home/indy/indy-sdk/libindy
RUN git fetch
RUN git checkout 778a38d92234080bb77c6dd469a8ff298d9b7154
RUN /home/indy/.cargo/bin/cargo build

Seems to take the most time, other than maybe rustup, during this build. Curious if it's absolutely necessary to build libindy to make this von-network image. I know that the upstream repo probably does it, but my thinking is that we could do better than that. I'm guessing that the Sovrin repo offering of libindy is not at a recent enough build to be usable? Could we maybe change the indy_stream parameter to grab a later package instead of building indy ourselves?

And then I have a few related questions to the above question. Assuming for a second that we don't need to build libindy (which is a big assumption, I know), do we need to install Rust?

I know that the SDK was written in Rust, but it seems that it has bindings into other languages (like Python) that we could capitalize on, by just installing the binding instead of building from scratch?

In general, I'm a believer that Docker containers can be useful for building software projects, but that there's a difference between building a docker image that is useful for building a software package, but it is a separate enterprise to build a Docker image for running/serving/executing the package. In this case, what I'm saying I guess is that to me it doesn't make sense to build the thing in the same container in which you use it.

I'm asking about this and many other issues on this repo because I'm trying to determine how amenable the owners would be to PRs that change/shift things. If the feeling is that my ideas here are a bit to zany or that maybe they are good ideas but there's other more important things than even reviewing PRs that could address some of these issues, then I won't bother. I'm not saying "this is something you need to fix", I'm trying to say "is this something you would consider fixes on?"

nrempel commented 6 years ago

Hey Ben, we are absolutely open to pull requests for fixes and improvements. That would be much appreciated 😁

swcurran commented 6 years ago

We're doing this things suggested here - optimizing the execution image, separating out the build and run images, etc. We'll soon have a Docker Hub hosted image that we'll use for the majority of the runtime for the projects, eliminating the need to do that within the projects.