search

mlabs-haskell / lambda-buffers

LambdaBuffers toolkit for sharing types and their semantics between different languages
https://mlabs-haskell.github.io/lambda-buffers/
Apache License 2.0
29 stars 0 forks source link

Use plutus-ledger-api-rust in extraSources #191

Closed szg251 closed 5 months ago

szg251 commented 5 months ago

I'm not sure this is wise, until we have automation that publishes these releases this can end up check mating us easily.

TBH, it's much more painful without versions (directly using git). The pla version, lbr-prelude and lbr-prelude-derive version must match, otherwise rust will think that there are multiple different Json traits. This means that even if lbr-prelude and lbr-prelude-derive are unchanged, updating lambda-buffers in a project would break.

This could be mitigated by your other comment:

Also, is there a reason these deps are not added through Nix extraSources? That way we could actually update via nix flake Update.

This would be a possible solution.. I would personally prefer to rely on crates.io in the long run (it's just simpler to find the corresponding documentation for the given version). But until we figure out how to automate, I'm the gatekeeper, which is not a good idea indeed.

I'll play around with this a bit

szg251 commented 5 months ago

@bladyjoker I reshuffled things as you suggested, we need to merge this first: https://github.com/mlabs-haskell/plutus-ledger-api-rust/pull/24

When we have both version and path, path will be prioritised for the local environments, and version is used when publishing the crate, so for packages we don't intend to publish, there's no need to add the version.

bladyjoker commented 5 months ago

Missed this!

I'm not sure this is wise, until we have automation that publishes these releases this can end up check mating us easily.

TBH, it's much more painful without versions (directly using git). The pla version, lbr-prelude and lbr-prelude-derive version must match, otherwise rust will think that there are multiple different Json traits. This means that even if lbr-prelude and lbr-prelude-derive are unchanged, updating lambda-buffers in a project would break.

I'm ok with versions!

This could be mitigated by your other comment:

Also, is there a reason these deps are not added through Nix extraSources? That way we could actually update via nix flake Update.

This would be a possible solution.. I would personally prefer to rely on crates.io in the long run (it's just simpler to find the corresponding documentation for the given version). But until we figure out how to automate, I'm the gatekeeper, which is not a good idea indeed.

I'll play around with this a bit

I really don't think we should do a roundabout through Crates until we have a working and automated release process. This can easily become a problem otherwise. Imagine an urgent hotfix and you being on vacation.

I personally don't know how to work with Crate and don't really have a strong desire to know much about publishing there. We also don't publish to Hackage for the same reason.

szg251 commented 5 months ago

I personally don't know how to work with Crate and don't really have a strong desire to know much about publishing there. We also don't publish to Hackage for the same reason.

My main motivation to get these onto Crates.io is the convenience factor: you get all the documentation automatically at a central place (I guess the same would apply to Haskell packages ... I don't know how much time could I have saved if Plutus was on hoogle), everything is a lot more discoverable. Also, plutus-ledger-api should be available to everyone, not just nix users, and lbr-prelude is a dependency of that.

But now I made it optional, so lambda buffers users don't have to deal with crates.io.