For stabilizing 1.27.x, the only issue I’ve heard ...
# announce
For stabilizing 1.27.x, the only issue I’ve heard is a user having an issue with Python targets now enforcing they only have
files. They knew they were doing things wrong and I was trying to help them fix it (interaction with custom plugin), so seemed fine with the change. But, it does point out we didn’t do a deprecation cycle.
Should we convert it into a proper deprecation with a warning? It’ll make the code complex, but that’s not what we should optimize for
possibly, yea. i don’t know how widespread it is, but hitting a case that quickly is surprising
👍 1
it’s odd that it has to do with custom plugins though… were they creating a python target in a plugin?
Okay, so then that means a new RC with that, right? And we wait 5 days for that RC, so if I do it today, then we can land 1.27.0 on Monady?
were they creating a python target in a plugin?
Yes, a target that subclasses
but represents configuration for an ETL job. They did it this way for invalidation to work how they wanted, whereby only changes to the directory triggered a rebuild because the whole directory was included in the plugin’s targets `sources`; iirc, they don’t want transitive deps to cause invalidation. The change I suggested is to move those sources into a direct dependency, and use
to get that same invalidation. cc @wonderful-iron-54019
happy to answer more dertailed questions
have an upgrade to 1.26.0 in the wings, will then have to move on to other work but hoping to quickly follow up with another upgrade
❤️ 1
honestly this set up has been bugging me for a minute so being forced to fix is kinda of nice 😭
😅 2
the issue is that the code target and the ETL target both 'claim' ownership of a resources target
so we need to fix our ETL target setup to get that to work but htat was the plan
got it.
Rolling back the
file change to be a deprecation: JP, we’ll cherry-pick into 1.27.x.