need a little help upgrading to 1.29.0, specifical...
# general
w
need a little help upgrading to 1.29.0, specifically around backing out a hacky custom target while retaining the same functionality. I can give a short request and provide more context as needed. details in thread
essentially i want my custom target to also respond like a python library with
setup_py: recursive
turned on
as in i'd like it to trigger builds of dependent libraries when it is detected as changed, even tho it itself is not a python_library
we had worked around this, originally by having the custom target be a subclass of PythonLibrary and ignore the wheel file it produced
however, we also package yml files in our wheels, and we can no longer include them in
python_library
sources
and adding a
resources
target was causing ambiguities determining the owner between our actualt library and the custom target
so i've removed that inheritance
however, now that i've done that.
./pants deploy custom_target
does not build the code it depends on
hope that all is relatively clear
h
cc @hundreds-father-404 but the v2 target API was specifically designed to allow this sort of thing (it uses a sort-of duck typing for target fields, so as long as your target has the field types required to act as a python library, it will be treated as one)
w
this is a v1 target
h
Gotcha
w
also to be clear i said this was a 1.29.0 upgrade, but it's really 1.26.0 -> 1.27.0, im just trying to get rid of deprecation warning related to 1.29.0 before i proceed
so if the answer is to convert it to a v2 target that might work but im under the impression that 1.27.0 is missing some key v2 features
for more context. I'd like to deploy the stable
1.x
versions one at a time, before we g et more heavily involved in migrating to v2
h
V2 is good in 1.27, but indeed better in 1.28 We removed the restriction that Python targets can only have .py files until 1.29. Would it work to restore the inheritance chain for V1? And then I’d be happy to help rewriting it to a V2 plugin
w
right. what im trying to avoid are thousands of deprecation warnings for my teams upon upgrade
h
Ah you can silence those. See https://pants.readme.io/docs/upgrade-tips
w
but indeed better in 1.28
what do you mean when you say this?
is a v2 target going to need significant rework
h
(I’m wondering if we should have every deprecation warning point to this page. Few people know you can silence deprecation warnings)
w
id also like to batch cosmetic changes to BUILD files into as few upgrades as possible
👍 1
h
is a v2 target going to need significant rework
Between 1.27 and 1.28? No. there aren’t any major changes to the Target API, beyond the function name changing in
register.py
from
targets2
to
target_types
. 1.27.x is actually a fine version to start using v2. The main benefit you’d get in 1.28.x is better UI output, and in 1.29.x a slight speedup to resolving Python requirements through better caching
Remind me - is this specific plugin only setting up a new target type, or you also have a Task to go along with it?
w
i have two tasks to go along with it
those two tasks essentially just delegate to a subprocess
ah good news, got around this by just changing my custom targets default sources. 🤦🏼
h
Oh yay!
Your V1 or V2 target?
w
v1
again, woudl prefer to get to a 'stable'-ish version of v2, then do the work on task -> rule conversion
👍 1
h
Cool. Well, glad it’s working now. Let us know if you run into any other issues. Also, with the jump to 1.29.0, you’ll be able to use the new Pylint first-party plugin feature 🙂
w
yes the goal is to get to 1.30.0 before the month is out
🎉 1
❤️ 2
then i'd feel comfortable being a v2 guinea pig
@hundreds-father-404 ok i lied, this change worked in one case but i think this was just a function of our target graph and where things were defined, its still happening elsewhere. It's a bit late for me right now, but I'll play around with it tomorrow morning and pop back on here for help if needed
👍 2