On Fri, Dec 09, 2016 at 10:45:05AM +0000, Edd Barrett wrote: > Hi Sebastien, > > On Thu, Dec 08, 2016 at 04:30:27PM +0100, Sebastien Marie wrote: > > Hi, > > > > I started to discuss, mainly with landry@, on how to properly use Rust > > ecosystem inside ports. > > I don't know much about rust, but I have dabbled with cargo and it seems > golang has a similar package manager where you list deps and it > downloads the source code and statically links them in to the resulting > binary. And like rust, different projects can ask for different versions > of dependencies. > > For golang ports, we've been asking upstream to make a "vendored" > tarball, which contains the frozen source codes of the dependencies. The > tool used to make the tarball is govendor [1]. Not sure if rust has > something like this? If cargo has a "fetch" step, perhaps you can roll a > tarball after this step and use this for porting. > > Admittedly such a solution makes no attempt to share dependency > distfiles. > > [1] https://github.com/kardianos/govendor >
Thanks for sharing experiency with go. cargo has also a vendor tool (https://github.com/alexcrichton/cargo-vendor) to automatically download all dependencies, and place them in a directory that cargo will use when building. In fact, the cargo.port.mk module I develop use a part of this mecanism. If the crates list is done semi-manually, the last part is the same as cargo-vendor: it generates metadata for each crate, and configure cargo to use them instead of looking at network. The advantages of the module over cargo-vendor are: - crates are downloaded individually (so share between ports is possible) - the metadata is generated at post-patch stage: it allows patching on a crate. cargo-vendor doesn't have this purpose: the metadata normally ensures the crate isn't modified externally (sha256 of each file). -- Sebastien Marie
