Add pants_from_sources support.

[jsirois]

Closes #30

[jsirois]

1 extra commit coming to add CI caching of ~/.cache/scie-pants/dev since its so slow to build the Pants used for the pants_from_sources tests - but safe to review.

[kaos]

Ah, I see.. is this also closer in line with how you'd prefer to solve #33 ?

Or, doesn't this also cover the use case for #33 ?
Edit: uhm.. maybe not, if it's to magically switch behaviour only in the face of the magic config. Only, now for #33 we could re-use some of the logic in here, I believe..

[jsirois]

Ah, I see.. is this also closer in line with how you'd prefer to solve #33 ?

This really bears no relation to #33 in that it is completely driven by preexisting requirements. The pants_from_sources scripts totally constrained what I could do here. There were 0 choices for me to make afaict.

#33 can be solved by using any unambiguous marker. If and only if it's decided the marker lives in pants.toml / is an env var, then the soft constraint of not grabbing more subsystem name land is to re-use bootstrap which was grabbed by PANTS_BOOTSTRAP_TOOLS before scie-pants was even an idea.

[kaos]

Sorry I was being very vague in my phrasing of that question. Having just reviewed the implementation I was thinking of the implementation--regardless of how we detect that we want to delegate to a ./pants bootstrap script--in main.rs I had made another lift-entry for pants-dev, where as here you made another get process function altogether. I see those as two different ways of solving this, and both could work for #33 as well, I think. So, seeing this method here now, in contrast to what I cooked up in #75 I was wondering if this approach may be preferable to having that extra lift-entry?

But, we can defer this topic to the review of #75. :)

[jsirois]

But, we can defer this topic to the review of #75. :)

I answered there, but the key difference in "commands" delegation is the need for "bindings" (~install setup steps). You do not have that need.

[benjyw]

Sorry I'm late to the party, but it occurs to me that PANTS_SOURCE lives in the PANTS_ namespace of Pants options. E.g., if we add a global option named --source, this would stomp it.

In fact, we already have a "source" subsystem, for source root configuration, so PANTS_SOURCE_* is occupied. This doesn't collide with PANTS_SOURCE, but I wonder if it's close enough to be confusing?

Should this be _PANTS_SOURCE? Or maybe this isn't a real problem in practice.

PS I like the env var a lot more than pants_from_sources and will be using it exclusively from now on.

[jsirois]

Yeah, the current choice matches status quo, but I do agree status quo is confusing. I'm on a mission to do a narrow thing: replace ./pants and not break people. If you or others want to follow up and do other things, that's great.

[benjyw]

Uurgh, didn't realize we were using PANTS_SOURCE inside pants_from_sources today.

I'll think about whether this is worth changing.