# External contributions to the SDK are blocked by private dependencies

**URL:** <https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784>\
**Category:** Command Line Tools\
**Created:** [March 30, 2022, 1:20am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784 "2022-03-30T01:20:36Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [March 30, 2022, 1:20am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/1 "2022-03-30T01:20:36Z")

</div>

The [`dfinity/sdk`](https://github.com/dfinity/sdk) repo depends on a private `dfinity-lab/common` repo.

This means that anyone without access to that repo who would like to contribute to the SDK immediately runs into the issue below when following the [contributing guidelines](https://github.com/dfinity/sdk).

> <https://github.com/dfinity/sdk/issues/1955>
>
> https://github.com/dfinity/sdk/blob/master/nix/default.nix#L5-L11
> 
> This commen…t does not explain where to obtain the common repo, and the one it provides as a fallback does not exist:
> git@github.com/dfinity-lab/common

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [March 30, 2022, 1:22am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/2 "2022-03-30T01:22:32Z")

</div>

Sharing here for some additional visibility since the issue is 6 months old and there doesn’t seem to be any sign of changing things yet.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [March 30, 2022, 8:00am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/3 "2022-03-30T08:00:42Z")

</div>

Yes, would be good to have this fixed. Given that the `ic` repo doesn’t use `common` anymore, maybe simply copy the relevant files to `sdk` to make it self-contained? Surely some engineer at DFINITY can do that more quickly than going through a full open sourcing exercise for a repo that probably nobody really cares much about any more.

---

<div class="post-metadata">

**Author:** ![ericswanson](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ericswanson/32/622_2.png) [@ericswanson](https://forum.dfinity.org/u/ericswanson)\
**Post date:** [March 30, 2022, 3:51pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/4 "2022-03-30T15:51:02Z")

</div>

The contributing guidelines are out of date. It’s now possible to build dfx with `cargo build`, no nix or common needed.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [March 30, 2022, 7:27pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/5 "2022-03-30T19:27:06Z")

</div>

But it’s nice to use nix 🙂

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [April 1, 2022, 2:14am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/6 "2022-04-01T02:14:08Z")

</div>

Having just submitted [feat: Introduce DFX\_CACHE\_ROOT environment variable by paulyoung · Pull Request #2112 · dfinity/sdk · GitHub](https://github.com/dfinity/sdk/pull/2112) I can say that it would have been great to be able to use the Nix derivation provided for running the end-to-end tests locally.

---

<div class="post-metadata">

**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\
**Post date:** [April 8, 2022, 6:18am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/7 "2022-04-08T06:18:11Z")

</div>

Guidelines have been updated. No nix mentioned anymore. Have fun!

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [April 8, 2022, 4:12pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/8 "2022-04-08T16:12:48Z")

</div>

@paulyoung, guess they really really don’t want us to use the nix file there. We may have to `buidRustPackage` it externally, essentially recreating the build setup…

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [April 8, 2022, 4:43pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/9 "2022-04-08T16:43:37Z")

</div>

Pretty much - you’re welcome to use Nix for your own setup, but we’re committed to removing it as a requirement/expectation in projects that accept community contributions

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [April 8, 2022, 5:02pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/10 "2022-04-08T17:02:43Z")

</div>

Oh, this isn’t about _requiring_ external contributors to use nix, merely _allowing_ it at least as long there is a nix setup in that repo. (If the `sdk` repo didn’t have a working nix setup we wouldn’t be asking for one, but it seems it has one that we can’t use for unsatisfying reasons.)

Of course if the nix setup in the `sdk` repo is stale and doesn’t work anymore anyways, then that’d be a different thing. But then it probably shouldn’t be there anymore… 🙂

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [April 11, 2022, 4:37pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/11 "2022-04-11T16:37:50Z")

</div>

Being able to build from source in a way that’s guaranteed to be reproducible would help in situations like the one I’m in now where a PR has been merged but the changes haven’t been released yet.

If the derivations in the SDK repo are being phased out I’d like to take what’s there now and get them working without the private dependencies.

I’ve seen the benefit of using Nix for the past 6 years and would like to keep using it for my own projects.

@ericswanson @Vivienne do you have any advice on what it would take to replace what’s missing from `dfinity-lab/common`? I attempted to do this recently by stubbing things out and following errors but didn’t get very far.

@nmattia, would you or someone else familiar with Nix be willing to help?

---

<div class="post-metadata">

**Author:** ![ericswanson](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ericswanson/32/622_2.png) [@ericswanson](https://forum.dfinity.org/u/ericswanson)\
**Post date:** [April 11, 2022, 8:25pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/12 "2022-04-11T20:25:19Z")

</div>

> if the nix setup in the `sdk` repo is stale and doesn’t work anymore anyways

This is closer to the truth. It works, but there’s come maintenance burden associated with making dfx build both with nix and with `cargo build` outside of nix.

Some of those issues might be more about building under hydra or other underlying problems rather than about building in nix itself.

Examples:

- `cargo build` now takes care of gathering assets ([sdk/src/dfx/assets/build.rs at master · dfinity/sdk · GitHub](https://github.com/dfinity/sdk/blob/master/src/dfx/assets/build.rs#L47)), while when building under nix we use a derivation ([https://github.com/dfinity/sdk/blob/master/assets.nix](https://github.com/dfinity/sdk/blob/master/assets.nix)).
- The agent-rs default branch is now called `main`, not `master`, but something in common expects it to be `master`. For the time being, our workaround is to update the `master` branch to the head of `main` when we update the rust agent, in order to avoid hydra evaluation errors.

---

<div class="post-metadata">

**Author:** ![nmattia](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nmattia/32/3726_2.png) [@nmattia](https://forum.dfinity.org/u/nmattia)\
**Post date:** [April 12, 2022, 7:47am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/13 "2022-04-12T07:47:04Z")

</div>

> @nmattia, would you or someone else familiar with Nix be willing to help?

I’m not sure this would be such a good idea, here are some observations I made when hacking on the repo last week:

- I was able to get a working shell using this: `nix-shell -p cargo -p darwin.apple_sdk.frameworks.Foundation -p pkg-config -p openssl -p libiconv` (macOS)
- All .nix files should probably be removed if they’re not used, right now they’re just confusing, and
- I was extremely surprised to have a `build.rs` actually downloading things; I don’t expect the build process to download things or generally need access to the internet.

---

<div class="post-metadata">

**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\
**Post date:** [April 12, 2022, 8:29am UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/14 "2022-04-12T08:29:14Z")

</div>

> [@nmattia](#):
>
> All .nix files should probably be removed if they’re not used, right now they’re just confusing

Agreed, I’ll discuss this with @ericswanson and vote for this.

> [@nmattia](#):
>
> I was extremely surprised to have a `build.rs` actually downloading things

I speculate this is the alternative to internal nix dependencies.

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [April 12, 2022, 8:29pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/15 "2022-04-12T20:29:40Z")

</div>

> [@nmattia](#):
>
> I was extremely surprised to have a `build.rs` actually downloading things; I don’t expect the build process to download things or generally need access to the internet.

This is exactly the issue I ran into which unfortunately means I’ll probably abandon the idea of building from source.

---

<div class="post-metadata">

**Author:** ![ericswanson](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ericswanson/32/622_2.png) [@ericswanson](https://forum.dfinity.org/u/ericswanson)\
**Post date:** [April 13, 2022, 6:47pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/16 "2022-04-13T18:47:44Z")

</div>

If having build.rs download things is a problem (which I have run into on certain environments, for example the [musl build action in a GitHub workflow](https://github.com/dfinity/sdk/blob/master/.github/workflows/publish.yml#L71)), you can:

- run `./scripts/prepare-dfx-assets.sh <some path>`
- set the `DFX_ASSETS` environment variable to that path

Then `cargo build` via build.rs will use the assets that are already prepared, rather than calling that script itself.

The reason for build.rs to do this in the first place is so that `cargo build` works after cloning the repo, or in IDEs, or anywhere else that you’d expect `cargo build` to work, without further setup, and also updates those assets after `cargo clean` or `git fetch` or other actions that change the inputs for those assets.

---

<div class="post-metadata">

**Author:** ![ericswanson](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ericswanson/32/622_2.png) [@ericswanson](https://forum.dfinity.org/u/ericswanson)\
**Post date:** [April 13, 2022, 7:25pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/17 "2022-04-13T19:25:15Z")

</div>

> [@nmattia](#):
>
> I was extremely surprised to have a `build.rs` actually downloading things; I don’t expect the build process to download things or generally need access to the internet.

The prior state that you could only build with `cargo build` if you’d also installed nix, and used that to build (download) these assets, and set DFX\_ASSETS to point to the the resulting output directory. We wanted to make it so you could build by cloning the repo and running `cargo build` , which seems like a reasonable expectation for a rust project.

---

<div class="post-metadata">

**Author:** ![nmattia](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nmattia/32/3726_2.png) [@nmattia](https://forum.dfinity.org/u/nmattia)\
**Post date:** [April 21, 2022, 2:04pm UTC](https://forum.dfinity.org/t/external-contributions-to-the-sdk-are-blocked-by-private-dependencies/11784/18 "2022-04-21T14:04:50Z")

</div>

For the record, I’ve described a potential solution [on the GitHub tracker](https://github.com/dfinity/sdk/issues/2148).
