https://pact.io logo
Join Slack
Powered by
<@U9UUY3CU9> <@UELMFD9PG> I'm thinking of pulling ...
# maintainers
r
@Matt (pactflow.io / pact-js / pact-go) @Yousaf Nabi (pactflow.io) I'm thinking of pulling the mock server crates out of the current repo into it's own repo. The reason is I want to start a redesign/rewrite for a V2 version, and it is easier to support multiple versions with branches if it is not in a mono-repo. We currently have 
pact-mock_service
repo which is the old Ruby version, so creating a 
pact-mock-server
repo will be confusing (but not to me). So need to start with a repo name.
Can probably do the same with the verifier crates at some point.
j
I guess the main question for me is how often we make simultaneous releases, because simultaneous releases from a monorepo is a lot more straightforward. Having not worked on these crates, I don't really have an opinion either way.
r
The mock server crates have hardly changed in the last few years, and are released independently from the other crates
👍 2
m
I don't have an opinion on the splitting. I wonder how we expedite the decommissioning of the Ruby libraries so we don't need to support both (to your point about confusion of naming) @Yousaf Nabi (pactflow.io) has been playing with that, but perhaps we should raise it to the level of an official project to be completed
y
I’m on board. would be want to split out the verifier as well? naming wise okay keeping it as is as we can use guidance to support what the user should be user and clearly mark in the readmes, spec support and status. so for each ruby lib point to its rust replacement does it make sense to make pact-reference - pact-core or split into seperate repos per crate. not sure how much value the examples ( python, js ) add anymore, with those languages being fleshed out now. on the expedition of the decomissioning of the ruby libs, ive looked at a few options and pathways 1. create a top level pact tools doc page rather than landing on the cli tools overview https://docs.pact.io/implementation_guides/cli 2. on the docs page show tools ( cli / available lang impls) 3. for each cli, show links to current ( rust ) and legacy (ruby) 4. for each legacy cli provide a migration path to rust cli 5. implement pact broker client functionality in rust, I’ve been making a start on this whilst learning rust after hitting a point of diminishing returns in the land of ruby packaging. https://github.com/YOU54F/hello_cli - warning code may make rustaceans cry 1-4 should help users navigate the current landscape and provide more context to the available tooling, which we don’t have currently 5 should mean that to all intents and purposes we can stop talking about ruby as anything other than heritage with exception to the pact broker, and support ruby language end users in implementing a ruby client dsl over the ffi. I’ve got some samples in place in https://github.com/YOU54F/pact-ruby-ffi as a bit of an aside, but maybe a good opportunity. It appears that cargo fmt and my editor want to fight against the current code, and I feel like this might be an impediment to contributions. How would you feel about taking the commit history hit and adding in a linting step. oh and with regards to the cli, i took an opinionated move to roll all the existing cli crates into one project, so it just built one executable. This saves on disk space and makes it easier just to have all of Pact in one place, which for me, makes the story of Pact just easier to tell in general. The entry point could be the cli rather than reams of documentation up front. thoughts on a postcard? its nothing that can’t be undone and its been a good learning exercise on personal time. I’d love a cli where users could easily extend themselves, the gh cli is a create example of where users can register subcommands and the really nice thing about their impl, is users don’t have to code in golang, it could be a shell script, or a binary from any lang. If we wanted to increase user exposure to rust, cli’s seem like a nice way to dip your toe in. I’d love to explore how users could extend the rust cli, by either integrating into their own cli tool written in rust ( maybe clap builder is exported from each crate and can be integrated into a users cli, or they can easily add in their own crate for a subcommand ) sorry brain dumping again haha
can we normalise hyphens and underscores between the rust projects, we have pact-stub-server and pact_mock_server_cli can we do one or the other across the rust projects.
can we also give some thought to guidance for contributors on how to setup a workspace for building the whole meta project if they need to make a change in pact_models, and they want to pull it through into one of the other crates. One would imagine most of the external contribs are going to come from users leveraging pact through the ffi and would want to test it e2e in the respective client lang it might be clone x repos, setup x workspace, link to crates via path etc. I would have liked something like that to have bootstrapped the ruby projects as they are split into i think 6 gems
I wonder how we expedite the decommissioning of the Ruby libraries so we don't need to support both (to your point about confusion of naming)
better guidance in the repo and docs site would go far
@Yousaf Nabi (pactflow.io) has been playing with that, but perhaps we should raise it to the level of an official project to be completed
with the pact broker client being the only critical func left in ruby, fully stable and currently on the latest stable ruby version, I’m a little less concerned about needing to deprecate this asap. what i would like to investigate, is porting the func over to rust, with also consideration to the availability of it through client language wrappers, so the ffi basically, to allow users who’ve lost that native lang wrapper over the pact broker client, as we moved to rust ffi unless we also package ruby alongside which many projects seeked to drop completely. do we want to do that, or is just using the cli a better way forward? if its via the ffi as well, then existing rust ffi users can leverage from the same shared lib. was the maint effort of these wrappers such a burden that this is a futile endeavour. I think that could be somewhat overcome by a couple of approaches • ffi interface generators, I’ve played with a few, and create a fair few from knowledge of what an implemented interface looks like and working backwards to template it • having args as json object with ffi func taking a single param. the json message could be tested with pact to give cli/ffi authors feedback on who is using what and the impact of removing/adding a new field. okay so maybe after writing that we probably do want to have a separate topic/project listed somewhere about the decommissioning of the pact broker client looks like. 😅
r
Open in Slack
PreviousNext
Powered by