misc: develop against vendored dependencies #462
Conversation
bikallem
force-pushed
the
vendored-dependencies
branch
from
798087b to
2b54222
Compare
bikallem
force-pushed
the
vendored-dependencies
branch
2 times, most recently
from
44eb1ef to
9dd5214
Compare
.gitignore
Outdated
| random/ | ||
| vendor/ |
There was a problem hiding this comment.
You don't need this any more either...
There was a problem hiding this comment.
hmmm ... git seems to want to include things in this folder and it always lists it when doing git status. Of course you can do selective git add ... but mostly I prefer the convenience of git add --all. This prevents from mistakenly adding things from vendor dir to this repo.
|
Since there's quite some discussion about "vendoring" and "dependencies", is that somewhere documented what needs to be done and how to address issues? Is there a general move in the OCaml and opam ecossytem to add at random places "vendor"? I'm not a huge fan, especially since I've a hard time understanding what this "vendoring" is trying to solve, and how it works workflow-wise (including upstreaming diffs, etc.). |
| @@ -10,6 +10,7 @@ | |||
| server-ec.pem | |||
| server-ec.key | |||
| (package tls-eio) | |||
| (package mirage-crypto-rng-eio) | |||
There was a problem hiding this comment.
this change looks like an actual independent bugfix - which is fine to be merged in a separate commit (and PR)
There was a problem hiding this comment.
I think this is only necessary in a vendoring situation like this PR, thus the change. Outside of the use-case, i.e. vendoring your dependencies - this is not needed as before this PR.
|
Likely there exist some "vendoring" documentation, so maybe @bikallem or @avsm would mind to point to that? Is this "opam-monorepo" a part of it (or "opam lock")? I'm still puzzled, but maybe I just settled on a very arcane development style. Would love to hear how you people are working and which tools you're using. |
|
The vendoring approach used here is documented here https://dune.readthedocs.io/en/stable/dune-files.html#vendored-dirs-since-1-11. I am using vendoring here mainly so that I can insert 'printf traces/Eio.traceln' to tls-eio dependencies located in 'vendor' dir. This PR makes working with such vendored dependencies a little bit precise. |
bikallem
force-pushed
the
vendored-dependencies
branch
from
9dd5214 to
e688c08
Compare
|
Since @talex5 contributed the "eio/tests/dune", and my knowledge of mdx and dune is rather limited, I'd like to hear his opinion whether this PR is reasonable. Thanks. |
CHANGES: * BREAKING: new opam package tls-lwt (formerly tls.lwt), in dune: (libraries tls.lwt) should now be libraries (tls-lwt) (mirleft/ocaml-tls#468 @hannesm, reported mirleft/ocaml-tls#449 by @mbacarella) * tls: update to mirage-crypto 0.11 API (mirleft/ocaml-tls#468 @hannesm) * tls: relax SignatureAlgorithms extension handling to allow OpenSSL interoperability tests with TLS 1.0 and TLS 1.1 (mirleft/ocaml-tls#469 @hannesm) * tls: remove Utils.filter_map and and Utils.option, use Stdlib instead (mirleft/ocaml-tls#455 @hannesm) * tls: do not globally open Utils (mirleft/ocaml-tls#455 @hannesm) * tls: export log source of Tracing module (mirleft/ocaml-tls#461 @bikallem) * tls: remove unused ciphersuites to reduce binary size (mirleft/ocaml-tls#467 @hannesm) * tls-lwt: do not catch out of memory exception (mirleft/ocaml-tls#469 @hannesm) * tls-eio: add fuzz testing using crowbar (mirleft/ocaml-tls#456 mirleft/ocaml-tls#463 @talex5) * tls-eio: update to eio 0.7 (mirleft/ocaml-tls#456 @talex5) * tls-eio: fix test for develop with vendoring (mirleft/ocaml-tls#462 @bikallem)
This PR allows the dev repo to support developing, testing and debugging against vendored dune dependencies.
/cc @hannesm