Replies: 9 comments 2 replies
-
|
I am happy to see increased focus on the tests etc. (tbh, I had not even noticed the test Make targets you mentioned), but for clarity, I defer to @luss on this. If taken forward, I'd ideally like:
|
Beta Was this translation helpful? Give feedback.
-
|
we DEFINTELY need and want more testing. Else it's impractical to fix
minor issues because of the delicacy of multiplatform python and the
short-sheet effect
…On Sat, May 11, 2024 at 2:06 AM ShaheedHaque ***@***.***> wrote:
I am happy to see increased focus on the tests etc. (tbh, I had not even
noticed the test Make targets you mentioned), but for clarity, I defer to
@luss <https://github.com/luss> on this.
—
Reply to this email directly, view it on GitHub
<#44 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHXE3IIMJJHMM4ELM5LZBWYPFAVCNFSM6AAAAABHP2O6QKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGOJSG4ZDO>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Lets just support current versions of Python 3.9++, and current versions of Postgres 12++. I've opened up v3.0devel with these base changes and now (I feel) we are in poisition to modernize our tooling and to fix our bugs (like predicate pushdown) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing your thoughts. I think #46 misses on point 1 in @ShaheedHaque's comment. It doesn't quite make it so that "tests always run on a make" -- although it might be possible to change the default target to support that -- but it does document the test capability in the README, and bring test failures to visibility during merge. You could just use the nix test run as a build command... depending on what you're doing after the build. 😉 |
Beta Was this translation helpful? Give feedback.
-
|
I agree (as Mathieu suggested) that Nix testing replaces the docker crap. Mathieu please whack the docker testing stuff as per the commit u aborted. If anyone needs it, we can always go back and create a REL2_STABLE branch. We are moving forward smartly. Great stuff!! |
Beta Was this translation helpful? Give feedback.
-
|
Very kewl!! Unless someone abjects. I will tag a devel release and try
and do some tests build on pg16 and pg17. pg17 comes out bneta 1 later
this week.
…On Sat, May 11, 2024 at 1:03 PM Mathieu Fenniak ***@***.***> wrote:
Thanks for sharing your thoughts.
I think #46 <#46> misses on
point 1 in @ShaheedHaque <https://github.com/ShaheedHaque>'s comment. It
doesn't quite make it so that "tests always run on a make" -- although it
might be possible to change the default target to support that -- but it
does document the test capability in the README, and bring test failures to
visibility during merge. You could just use the nix test run as a build
command... depending on what you're doing after the build. 😉
—
Reply to this email directly, view it on GitHub
<#44 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHRDC7CWUAM6KJ7USDLZBZFPJAVCNFSM6AAAAABHP2O6QKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGOJXGM2TO>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
In v3.1, just recently opened up for devel, it is my objective that we support pg17 & py3.12. EZ for me to day... I sure hope someone will run/write some tests that (at least mostly) prove it. AFAIK, we've fixed any weirdown pushdown (or lack therof) erros for recent PG releases. If not, if someone can isolate a iple use cases that doesn't work. I'll get a PG internals hacker to look at our c code and figure out what's wrong. |
Beta Was this translation helpful? Give feedback.
-
|
Running the existing test suite automatically on new changes against more versions of Python & PostgreSQL will require very few modifications (assuming, of course, that they pass):
|
Beta Was this translation helpful? Give feedback.
-
|
:-) I will confess to not knowing how to run the existing tests. Have we
documented it somewhere so I can try it?
…On Wed, Sep 25, 2024 at 10:04 AM Mathieu Fenniak ***@***.***> wrote:
Running the existing test suite automatically on new changes against more
versions of Python & PostgreSQL will require very few modifications
(assuming, of course, that they pass):
- nix flake update at the root allows access to the latest releases of
PostgreSQL and Python that are packaged by nixpkgs
- The target test PG & PY versions are defined here:
https://github.com/pgsql-io/multicorn2/blob/3a77c129aa0ae865e3cfebfcd577fef53ec9e8fb/flake.nix#L24-L37
—
Reply to this email directly, view it on GitHub
<#44 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHS5PXCK62IT5OG3UA3ZYK7GNAVCNFSM6AAAAABHP2O6QKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZVGE4TQNI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You bet; it's noted in the README. https://github.com/pgsql-io/multicorn2?tab=readme-ov-file#integration-tests |
Beta Was this translation helpful? Give feedback.
-
|
ahh yesss! I do rember reading about multi-version python nix teasting in
the README. I'm old and forgetful. :-)
…On Thu, Sep 26, 2024 at 7:33 AM Mathieu Fenniak ***@***.***> wrote:
You bet; it's noted in the README.
https://github.com/pgsql-io/multicorn2?tab=readme-ov-file#integration-tests
—
Reply to this email directly, view it on GitHub
<#44 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHSHQ6OGNMIMEEMSRSTZYPWJLAVCNFSM6AAAAABHP2O6QKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZWGI2TENI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Is it expected in the current
mainbranch that the tests work? eg.make installcheck, or thedocheckscript? I haven't been able to get them to run successfully, but, I admit to using NixOS where everything is a little quirky.Would there be any interest in merging a patch that would...
The side-effects of the last point should be spelt out a little more. It would mean that a developer could run all the tests using this configuration only if they installed the Nix package manager (available for any Linux distro, MacOS, or NixOS). The environments available would be limited to those supported by Nix (eg. PostgreSQL 12-16 currently, Python 3.8 - 3.13 currently). And, if no other developers are familiar with Nix, it becomes difficult to improve or maintain these changes.
Nix is a good tool for this type of usage because it allows for a combination of a dynamic build and testing environment across all the different versions of those dependencies without having to install them in a way that makes them available system-wide. It's certainly not the only good approach, but it's one that I'm comfortable with and find powerful.
As an example of some part of what this would look like, I've packaged multicorn2 with nix so that I could use it to create a new docker image for dynamodb_fdw. The multicorn2 packaging is https://github.com/mfenniak/custom-nixpkgs/blob/main/multicorn2.nix; so some code similar to this, although configured to run
make installcheckacross all these different environments, would be what I'd be proposing to add.I'd enjoy the work in creating such a patch, but I thought it best to discuss such a thing before doing the work. If it wasn't a welcome contribution, I wouldn't want to blow through my time. :-)
Beta Was this translation helpful? Give feedback.
All reactions