[#nix] .lock file under sdk directory preventing daml to work

Questions
1

Hi,

In the project I work for, we use daml during our CI pipeline. Since we do use nix there, I thought we could nixify daml for that purpose. I managed to create really dummy derivation which almost work. Almost, because:

  • v2.0.0 - all (of the features we need) work fine - daml build, daml codegen java works as expected, our CI is happy,
  • v2.1.1 - v2.2.0 - daml crashes when daml build was executed with the following output: daml: /nix/store/pqj9ijpiz0l1bc4iwswqjqdf869dagxq-daml-2.2.0/sdk/.lock: openFd: permission denied (Permission denied)

Failure case is obvious but even when during the installPhase I create artificial (touch $out/sdk/.lock) .lock file under /nix/store/…/sdk directory, it still fails. Looks like daml really wants to write something there :slight_smile:

Can you please point me to the place in the code which I could patch somehow and then build daml from sources under my nix derivation? Or maybe there is some other way howto workaround this behavior?

Thanks in advance for any advice :slight_smile:

Best regards,
Karol

2

I don’t particularly recommend trying to build the daml SDK from source, but you may get away with just patching the daml assistant itself (i.e. the daml executable).

The offending function is here. Depending on your context, you may be able to just turn that function into a pass-through if you know there is no risk of parallel executions.

Note that the lockfile is typically used upon installing new Daml versions, so the assistant would need write access to the folder beyond the lockfile, as the most likely next action is to initiate a download of the appropriate SDK version. I suspect what is happening here is your Nix derivation has installed version X, and you’re then trying to run daml build in a project that requires version Y.

If that’s the case, perhaps a simpler approach would be to have a separate Nix derivation for each version of Daml you want to use (relying on the simple unpacking of the corresponding tarball) and use the Nix environment management tools to make sure you have the appropriate version of Daml available on your path for each project (e.g. with a shell.nix file per project), i.e. completely bypassing daml's version detection and auto-install feature.

1 Like
3

Thank you @Gary_Verhaegen

You’re right, I was trying to run daml 2.2.0 against project requesting daml 2.0.0 :man_facepalming:

Thank you once again for your answer :slight_smile:

4

You’re very welcome!

If your problem is resolved, would you mind marking the question as answered? It helps other people navigating the forum.