@lokeshrangineni thanks for giving this another look! PTAL at the linter output, but I'm going to go ahead and approve tests so we can get an idea how integration results look 👍

copying out the two error lines from lint job so we don't have to keep pulling context back up

feast/infra/materialization/contrib/bytewax/bytewax_materialization_dataflow.py:9: error: Module "bytewax.inputs" has no attribute "ManualInputConfig"  [attr-defined]
feast/infra/materialization/contrib/bytewax/bytewax_materialization_dataflow.py:10: error: Module "bytewax.outputs" has no attribute "ManualOutputConfig"  [attr-defined]

Are we dropping ci, but keeping support? shouldn't this PR change REQUIRES_PYTHON as well?

@tokoko please keep 'em coming, I'm just trying to work thru the required check, but I'm missing historical context. Appreciate the good feedback!

@jeremyary no problem :) I think we should definitely be running ci for the lowest version of python supported. Without that, we would very easily introduce changes and dependencies that would break the baseline version. that's just my opinion. The larger question here is whether we want to drop 3.8 support or not. I'm all for dropping it (and I kinda feel bad about stopping this PR :D ) but I think we should also agree on removal policy before doing that. We don't have anything documented and 3.8 still hasn't reached EOL. I posted on slack a couple weeks back suggesting to adopt NEP-29 instead of following official python deprecations. As much as I'd like to see 3.8 gone, there's probably a discussion to be had before doing that.

@jeremyary no problem :) I think we should definitely be running ci for the lowest version of python supported. Without that, we would very easily introduce changes and dependencies that would break the baseline version. that's just my opinion. The larger question here is whether we want to drop 3.8 support or not. I'm all for dropping it (and I kinda feel bad about stopping this PR :D ) but I think we should also agree on removal policy before doing that. We don't have anything documented and 3.8 still hasn't reached EOL. I posted on slack a couple weeks back suggesting to adopt NEP-29 instead of following official python deprecations. As much as I'd like to see 3.8 gone, there's probably a discussion to be had before doing that.

Thank you for the context. I am going to update the PR with the information you provided.

@jeremyary no problem :) I think we should definitely be running ci for the lowest version of python supported. Without that, we would very easily introduce changes and dependencies that would break the baseline version. that's just my opinion. The larger question here is whether we want to drop 3.8 support or not. I'm all for dropping it (and I kinda feel bad about stopping this PR :D ) but I think we should also agree on removal policy before doing that. We don't have anything documented and 3.8 still hasn't reached EOL. I posted on slack a couple weeks back suggesting to adopt NEP-29 instead of following official python deprecations. As much as I'd like to see 3.8 gone, there's probably a discussion to be had before doing that.

thanks again. A related thread's been going through our last couple of comm calls, though we didn't get into the procedural side. Without moving on from 3.8 we're stuck in a bit of a hard place around other dependencies that will soon stop supporting 3.8. I'm down for a collective rehashing via Slack if warranted, though cc @lokeshrangineni @etirelli @franciscojavierarceo

I have closed the this PR and opened the PR to test if the unit test cases job to run using python 3.8 have been removed or not.

Please find the new PR here - #3993