Hi <@U9WPJMT8Q>, I'm Tien, the one who created mer...
# pact-php
t
Hi @Mattermack, I'm Tien, the one who created merge request to use Rust FFI. I know you are busy, and that merge request is big, so it's hard to review. That's why I think we can split that merge request into smaller merge requests. To do that, I suggest we create a project so we can work together there. You can give advice, we can discuss, create merge request, review, track progress from there. I can think of 2 projects in mind: • Use Rust FFI • Support Plugins (CSV, Protobuf) We can start the latter after we finished the former. What do you think?
šŸ¤” 1
l
Can I ask why the rust FFI version still uses the ruby-standalone?
t
That's because there are code that need
pact-broker
binary from ruby-standalone, but I can't find any alternate version written in Rust yet.
šŸ‘€ 1
l
Thank you
I'm just seeing if I can get your code running faster than a patch for what is. But that is the very part I'd like to get rid of (well any sub-process calls really)
One potential part that can be pulled out that at least we agree on seems to be the updating of the API url to the new test.pactflow.io btw
t
Please create pull requests. I would like to see them.
l
t
šŸ‘ I will rebase into my code when it's merged
l
Your code has this. The point is that it can be a separate PR. Maybe all the choices could be.
in any case it's working for my local but failing in GitHub. Something else I know you'd mentioned to the pactflow team
https://github.com/Lewiscowles1986/pact-php/pull/3 is building now. Works on my local • removes additional
pact
folder for less changes than
master
• switches from
pact-stub-server.exe
to
pact-stub-service.bat
• uses updated pactflow.io url Less opinionated take is https://github.com/Lewiscowles1986/pact-php/pull/4 which avoids reverting changes to directory structure.
t
pact-stub-server which written in Rust does not work for you?
l
Doesn't appear in the zip for me
on ubuntu I just checked this is the same. So I've checked on Windows and Ubuntu
are you by-chance ensuring when you run locally you
rm -rf pact
between runs? I have been since I found that the nested
pact/pact
was a deeper issue. Originally I'd been running
master
then switched to your branch. Which mildly concerns me if people run an upgrade and was why I doubled-down on removing and just having one
pact
directory
y
@Tien Vo thanks for all your incredible work on this so far. I will do everything I can you help you all get this over the line. Looks like my good friend Lewis who has recently had eyes on the builds is here too so we are in the right place
l
@Tien Vo I mostly made similar changes (updated URL), but with the difference being that my fork of your branch does not change to the older seemingly un[der]maintained https://github.com/pact-foundation/pact-stub-server. I created https://github.com/pact-foundation/pact-stub-server/issues/47 to track one issue of getting rid of that.
It is still quite a large PR. I wonder if there is a way to make a list of things we want it to do, and then a list of the changes required, so that it might be easier to collaborate on smaller deliverables towards to goal.
t
It is still quite a large PR. I wonder if there is a way to make a list of things we want it to do, and then a list of the changes required
I didn't prepare that list yet. But I did suggest we can create that list in project so we can collaborate there (see my original message of this thread).
I think UPGRADE is a good starting point, we can break down items based on that list
l
Hey, Sorry I missed this. UPGRADE looks a great place to break things out. To be honest several of them look like standalone PR's As I can't create a project from the first link, do you think an issue might be a better starting point? GitHub supports
* [ ] sub-task
lists which can be used to tick off each item.
t
An issue is totally fine for me too.
I think the very first sub-task should be:
[ ] Discuss about a separate branch for 8.x code. Create new branch 8.x, or 7.x and work on master
l
m
Tein Vo & Lewis, as you probably noticed, I am hardly on Slack and mostly follow up on Github as I have the time. Thank you both for all those contributions! I recently posted something on where I have bandwidth: https://github.com/pact-foundation/pact-php/pull/270#issuecomment-1243043217. Not really sure how to best proceed.
t
Hi. Nice to hear that you have time to take a look at it again. My goal is to make the merge request about FFI smaller so it's easier to be reviewed. To do that, I have some idea (will be discussed in https://github.com/pact-foundation/pact-php/issues/262) • Decide the target branch for all the merge requests. Can you decide it first?
master
,
8.x
,
9.x
... • Offload installers (can you edit the ticket add this item?) • Offload console (can you edit the ticket add this item?) • Support FFI (can you edit the ticket add this item?) • Support Plugins (can you edit the ticket add this item?)
y
@Mattermack šŸ™Œ @Tien Vo thanks for still being motivated šŸ’Ŗ I have updated the ticket to reference your pointers above. I am really happy to help support this, my PHP knowledge isn't great, but I can muddle through, even to provide you all support in getting this out in beta for testing
t
Thanks šŸ™ . I will wait for decision on the first point, then start a new thread to discuss about the second point after that.
y
No problem dude, thanks. Following on from Lewis's comments before, I've created an org wide project called pact-php and assigned it to the pact-php project, to see if that will help us provide better tracking/visibility. Open to feedback, added this comment in the description
This is currently a beta - Trying to provide org wide tracking of projects in GitHub, by creating them against the pact-foundation organisation and assigning to individual repos
Unsure if that is the best approach, or if we should have a project around a theme
šŸ’š 1