https://pantsbuild.org/ logo
Join Slack
Powered by
I've been scouring, looking for where the ideas ar...
# development
p
I've been scouring, looking for where the ideas around multiple dependencies fields vs some mechanism to tag dependencies within the same field has been discussed. I couldn't find any proposal that specifically addressed this. Does anyone have some pointers? (links to what I've found so far in 🧵 )
Various issues and PRs that seem to touch on dependencies fields/tagging (where tagging is like "edge metadata"): https://github.com/pantsbuild/pants/issues/12794 https://github.com/pantsbuild/pants/pull/13922 https://github.com/pantsbuild/pants/issues/18320#issuecomment-1446953416 https://github.com/pantsbuild/pants/pull/18347 And most recently my PR (which adds a way to control dep traversal using a predicate/lambda that gets passed in the request): https://github.com/pantsbuild/pants/pull/19155
b
This was the proposal to change `file`/`resource` that was generally agreed upon that it needed to change. https://docs.google.com/document/d/1gdJjhfAiVymTTcV6sRmsHTvQrzgaFmXdY8-fkdFaqxc/edit?usp=sharing We never got past that, in terms of implementation, but the general consensus on Slack (very loosely used term here) was that we'd like have dependencies carry extra metadata
(Damn that's a year old too...)
p
(I often am surprised by how long doing things actually takes)
b
Well I never really started working on it 😅 You've now come farther than I ever have
p
Thank you for pointing me to that proposal! I looked at that and missed how the discussion was related.
b
Yeah sorry 😅
p
Adding support for multiple 
Dependencies
field is 😵 😵‍💫 🤯 ... That assumption touches so many things! Luckily, I don't think implementing all of that is required for https://github.com/pantsbuild/pants/pull/19155 to be merged, but I've taken a step towards whatever 
Dependencies
field solution we end up with (multiple fields or tagged deps).
Longer term, I think I would like to see tagged deps where 
Dependencies.calculate_values
converts each string into the given class. Then we could do something like this:
Copy code
archive(
    dependencies=[
        ":some_package",  # because package-able targets are distinct enough
        ":some_shell_sources" @ wrap_as(file),
        ":a_license_file",  # already a file
    ],
)
jvm_war(
    dependencies=[
        ":some_jar",
        ":other_thing_wrapped_in_jar",
        ":loose_files" @ l("content"),  # "l" is short for "label"
        *l(
            "content",
            ":another_loose_file",
            ":more_loose_files",
        )
    ]
)
@
is the 
__matmul__
operator (matrix mulplier). Overload that to create the "labeled" class implicitly. If not using the 
@
operator, then it returns an unpackable tuple of classes with the given label.
b
We already have @ to mean something. We can just use objects at this point. But we can bikeshed it later. I'm sure there are many ideas 🙂
p
Ah ha! I found a link to the "Intuitive Dependencies" proposal (and I added a link to it in the pantsbuild design docs dir): https://docs.google.com/document/d/1qMdiTDRz-891uyQ3D_e-NHbdUqS-tGo4_ROqyIlQfQo/edit#
Open in Slack
PreviousNext
Powered by