DEL-8132 extract DAML LF haskell libraries (scripted) #7246
Conversation
CHANGELOG_BEGIN Make Haskell libraries for DAML LF archives usable by other projects CHANGELOG_END
jberthold-da
force-pushed
the
DEL-8132-extract-daml-lf-haskell-libraries
branch
from
c1b66e8 to
d400b18
Compare
| mkdir -p "$DIR/protobuf/com/daml" | ||
| cp -RL "daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev" "$DIR/protobuf/com/daml/" | ||
| # generate code from protobuf using the matching tool, as a configure script | ||
| cat <<EOF >"$DIR/Setup.hs" |
There was a problem hiding this comment.
Custom setup scripts always end up causing problems at some point ime. Why did you decide against the approach the old script used which just used our Bazel setup to build the generated code and included that?
There was a problem hiding this comment.
The extracted library uses proto-suite-0.4.0.0 instead of the point between-versions used in the daml repo.
To use the released version, I need the packaged protobuf compiler => calling it in a custom setup.
There was a problem hiding this comment.
Can we just switch t a released version in the DAML repo? The more you diverge from the build setup used in the DAML Repo the more likely this is to break in the future.
There was a problem hiding this comment.
Happy to assist you in switching. I don't want to make that change on this PR, though.
IIUC it should be fine to just update the bazel configuration to depend on the (hackage-released) proto-suite-0.4.0.0. Is that right @garyverhaegen-da ? I can confirm all code in daml-lf-proto written against the generated Com.Daml.DamlLfDev.DamlLf* works with this version.
There was a problem hiding this comment.
I'm actually not very familiar with that side of things, but it seems to me we are depending on the release 0.4.0.0 version of proto3-suite per stack-snapshot.yml. What am I missing? Where is that "in-between version" we're using defined?
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
|
@jberthold-da What stability guarantees do you expect from us? So far, the DAML-LF AST we use in the compiler was an implementation detail. Now, you depend on it and we can't change it freely anymore. I'm not particularly happy about this. cc @bame-da |
|
@hurryabit we discussed this a bit last week. We provide zero stability guarantees and I recommended explicitly against using this. So this is very much a “use at your own risk” thing. Happy to provide more details elsewhere. |
We would like to use the LF reading libraries (DAML LF archive decoding to an AST) in a Haskell project.
An extraction script for these libraries once existed but is not available any more, so I have resurrected the script, adapted to current usage, and upgraded to the newest stackage LTS that can support it.
These libraries could be versioned manually to released SDKs and publsihed if desirable (without making any guarantees about the stability, therefore prefixing the version with
0..CHANGELOG_BEGIN
Make Haskell libraries for DAML LF archives usable by other projects
CHANGELOG_END
Pull Request Checklist
CHANGELOG_BEGINandCHANGELOG_ENDtagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines runtotrigger the build.