c
Hi :
bah, kbd slip.. šŸ˜›
ā€¦ well, Iā€™m considering the
--changed-since
flag which is one of the (many) most awesome features in Pants, and realize that Iā€™m missing a dependency on a targets lockfile for each resolve it is a part of.
There is a dependency to the
requirements.txt
file, which is all well and good, but it is actually the lockfile that is relevant.
as the contents of the lockfile may change without touching the requiremnts file.
b
Haha for a second I thought "gee I've gotten so out of practice with knit and crochet lately that I forget which stitch
bah, kbd, slip
is" which tells you how close my brain is to weekend mode...
c
šŸ¤£
b
Also I was distracted by the thought "Andreas! Yay!" I assumed you'd be kept busy by imanage for a good while.
c
cc @hundreds-father-404 may have some thoughts on the matter perhaps šŸ˜‰ ?
I assumed youā€™d be kept busy by imanage for a good while.
I am šŸ™‚ šŸ˜„
h
Hola. That would be tricky to pull off because no "target generators" can synthesize a
_generator_sources_helper
target for the lockfile. There is no natural place to generate that. Whereas
python_requirements
can generate it for its
source
field
e
Is this a generic issue with any configuration we allow that bypasses targets? I'm thinking of the proposed evolution of complete_platforms away from requiring a target. It seems like a generic big gotcha / bug in existing rules and when going to write a new one.
I want targets gone as much as possible, but if they are required for the current implementation of --changed then that seems to need fixing 1st.
h
Yeah it's a generic problem. For example, changing
.isort.cfg
should invalidate all Python targets where
skip_isort=False
, but it doesn't.
--changed-since
is imperfect and we say that in the docs
c
Hah, bummer. OK, Iā€™ll put a pin on that for a while then. Thx
OK, got an idea how to potentially solve this, Iā€™ll just need to find some time to test it see how it falls out šŸ™‚
But, in the mean time is there a way to manually add this dependency link? like adding a
file
target for the lock file and a dependency from the
python_requirements
to that, but I donā€™t want the lock file to actually be pulled into anything package wise, only used as a means to get targets to work on for the changed since option.
Aha! maybe an
experimental_shell_command
could work as go between, as a filter..
h
yep! Use the
_generator_sources_helper
target type, which has a
source
field
šŸ’Æ 1
c
Oh, right I could just put that in the BUILD file of course. cool! Thx Eric ā¤ļø
ā¤ļø 1
h
I don't think we have a ticket for this general problem btw, if you want to create one to track it
I still have no idea how we'd solve it, but at least worth documenting as an issue
c
I can create a ticket later tonight (Itā€™s a hassle to switch between GH accounts, as I have another one for iManage work)
šŸ‘ 1
That would be tricky to pull off because no ā€œtarget generatorsā€ can synthesize a
_generator_sources_helper
target for the lockfile. There is no natural place to generate that. Whereas
python_requirements
can generate it for its
source
field
What if the
python_requirements
generator also generates a
_generator_sources_helper
for each
resolve
as a resolve requires a lockfile, that should be fine! (and skip that if resolves are not enabled, naturally) Itā€™s just a matter of looking up the lockfile path for the each resolve.
(as was concluded in another thread, it wasnā€™t as easy to ā€œabuseā€ the
_generator_sources_helper
explicitly in the BUILD file, as I canā€™t add the dependency in a clean way)
> I still have no idea how weā€™d solve it, but at least worth documenting as an issue
I can create a ticket later tonight (Itā€™s a hassle to switch between GH accounts, as I have another one for iManage work)
https://github.com/pantsbuild/pants/pull/16934 @hundreds-father-404 Iā€™d love some šŸ‘€ on this (when convenient), and would like picking to 2.14.x if at all possible šŸ˜‰
h
thanks for working on this! that's really good polish
ā¤ļø 1