flat-zoo-3195201/14/2021, 4:04 PM
hundreds-father-40401/14/2021, 4:07 PM
will that change scale to other languages?Good question. I'll add a section sketching what Java might look like with this naming.
does it matter?Does which part matter?
flat-zoo-3195201/14/2021, 4:09 PM
or whatever the case may be there
hundreds-father-40401/14/2021, 4:18 PM
matters too imo A big insight I've had recently is a separation between targets describing 1) your own code, 2) third-party reqs, and 3) artifacts. We used to muddy that, like
being defined on a
field. Now, we have targets whose sole purpose is describing source files vs. targets for abstract metadata on how to build something For that first category, I'm thinking
should scale well
flat-zoo-3195201/14/2021, 4:51 PM
jolly-midnight-7275901/14/2021, 5:53 PM
contains the meta data for a group of python files that form a coherent "thing" (now known as a library)? I don't see how changing library to sources reduces the confusion. A python developer still needs to know that another target is needed for making a pex (
) and a wheel/zip (
). Are you trying to create the dichotomy between sources and 3rd party requirements? Requirements come from the
ecosystem. If you are going this route, why wouldn't you also use the name
jolly-midnight-7275901/14/2021, 5:54 PM
hundreds-father-40401/14/2021, 5:54 PM
Is the idea that python_sources contains the meta data for a group of python files that form a coherent "thing" (now known as a library)That's the thing, there need not be any coherence at all. It could be a single source file, or all your source files, or 5 of them etc. All it is is metadata over n number of Python files, which all share the same explicit metadata like
. Right now, we incorrectly suggest they must be coherent
jolly-midnight-7275901/14/2021, 5:55 PM
jolly-midnight-7275901/14/2021, 5:56 PM
hundreds-father-40401/14/2021, 5:56 PM
jolly-midnight-7275901/14/2021, 5:57 PM
files in this way, even with tooling to help.
jolly-midnight-7275901/14/2021, 5:58 PM
files through inference, then it won't matter as much.
jolly-midnight-7275901/14/2021, 5:59 PM
? Does that make sense given it defines metadata for a python only target?
hundreds-father-40401/14/2021, 6:22 PM
to live on a
. That became illegal to do once we added "file targets", it would break most the time. Which led to
, which led to this insight that there's a distinction between "metadata describing first party code" vs. "metadata describing something you want to build" -- FYI the major remaining churn we anticipate is wanting to solve the problem of it being hard to add explicit metadata to a granular part of your first party code, without needing lots of granular targets. A common pattern (now) is to have one
target describing >20 files thanks to
rglobs. When you add an explicit dep like a database that Pants can't infer, then now all 20 files get that even if only 1 file actually needs it. 111 mitigates this problem, but is extra boilerplate We're envisioning a way where you can somehow merge metadata, like say "these 200 files use these interpreter constraints; these 5 files have a database dep". Without needing to have distinct targets for everything. The trick is how do we do that in a way that isn't majorly disruptive... It's another big paradigm change we couldn't envision before dep inference because we were blinded by the way every monorepo Build Tool™️ has done things since the start.
hundreds-father-40401/14/2021, 6:24 PM
What about pex_binary?Eh, yeah, possibly it should have been
. But I think we're extremely unlikely to change it one more time. That's too disruptive. I think
makes sense because there are multiple ways you can create an AWSLambda. Personally, I wish we called
. But too late to change
happy-kitchen-8948201/14/2021, 7:18 PM
happy-kitchen-8948201/14/2021, 7:19 PM
is too confusing with the existing
hundreds-father-40401/14/2021, 7:19 PM
happy-kitchen-8948201/14/2021, 7:21 PM
can encompass multiple requirements.
hundreds-father-40401/14/2021, 7:24 PM
Maybe python_dependency?This sounds the most natural to me, but it's confusing with our
field meaning either 1st or 3rd party deps.
could make sense. I think I'm not super concerned about verbosity for this target type because it's not used frequently
flat-zoo-3195201/14/2021, 8:05 PM
flat-zoo-3195201/14/2021, 8:06 PM
hundreds-father-40401/14/2021, 8:08 PM
and our docs being able to consistently use the new names. That's fine to have hidden names for the same thing.
flat-zoo-3195201/14/2021, 8:09 PM
flat-zoo-3195201/14/2021, 8:09 PM
flat-zoo-3195201/14/2021, 8:10 PM
hundreds-father-40401/14/2021, 8:12 PM
there's not a really good name for the concept you describe: "a set of source files that share some common metadata",Agreed, and that speaks to the bigger thing that we're realizing we want to do, but don't yet know how, particularly in a way that we don't screw over current users: somehow replace the idea of targets for first-party code with this merging-of-metadata idea Targets seem to work well when describing third party requirements + artifacts you want to build. They map very nicely 1-1 with the thing you're describing. Targets get really clunky when describing first party code, though.
flat-zoo-3195201/14/2021, 8:13 PM
may be confusing for newbies, but i'd suggest that changing names doesn't universally solve that problem, since a newbie approaching an existing codebase that uses it (either due to people pinning their versions back or backward-compatible aliases) will still have to make the mapping between that confusing term and whatever new term you use in docs or in
flat-zoo-3195201/14/2021, 8:14 PM