Q: Why is having no constraints/lockfile of any kind even supported? Seems so goofy to me

Surely you're joking? The bread and butter ecosystems for Pants anyway (JVM / Python) have historically not had these. So things start without them. And that's the end of the story. The rest is the difficulty of adding support once the ecosystem sprouts them or inventing them whole cloth when they don't. Mix in backwards compatibility, deprecation cycles and limited man hours and ... surely you're joking?!

I'm not. Even in Python's ecosystem, I have to declare my dependencies one way or another. Be it a

pip install

or

poetry add

Allowing a developer to add an import, which implicitly adds a dependency seems dangerous, especially for it being the default setting.

Ok, you mean going forward. Yeah, going forward this is something we are actively trying to get towards is my understanding. The devil is purely the details of not breaking the world in the process.

Do you ever see Pants not allowing the case where you don't have at least your direct third-party deps declared?

A few too many negatives there to parse easily! I don't see the status quo changing in the short to medium term; i.e.: You must write down explicit direct 3rdparty requirements be they loose, pinned or hashed. I do see the possibility of not having to do that though down the road. Pants or Toolchain or someone could provide a service that maps imports to 3rdparty requirements and declares these for you. In fact v1 did this for go code since it has a regular way to match up imports with 3rdparty code out on github, etc. That v1 go auto-gen though did error out after genning the 3rdparty deps and said you must now pin the dep I wrote down to a specific version. Until you pinned, the infra would error out. I think you had the option of flipping the error to a warning if you had good reason to live dangerously. I think there was no option to turn the warning off.

Yeah I think it makes sense as an opt-in. Being on by default seems dangerous 💀

I mean, the plugin system means we can't rule this out. Someone could do it despite what we decree.

YMMV with plugins. I think that's mutually understood

Yeah, I think 0 people have ever asked for this in Pants core. I don't recall a single ask or brainstorm about it.

Stu and I have discussed that we would like to make lockfiles at a minimum the default experience and you have to go out of your way to turn it off. In JVM land, you can't turn it off! Maybe we get there for Python? As John mentions, it's been a long journey to try to get there, and we're not yet there - possibly we'll always need the escape hatch because Python Packaging™️

To be clear, the effect of python packaging is not to do with lock vs can't and need an escape hatch. The only reason an escape hatch is needed is if your resolver and your locker have an impedance mismatch. For the JVM we don;t have this. For the early roll out of locking for Python up through now we knowingly went with an impedance mismatch, lock with Poetry, resolve with Pip. That's the only reason Python needed an escape hatch. If we resolved with Poetry too, then no escape hatch needed. The flip side is, people who needed --no-binary, custom indexes and find links, etc simply could not use Pants at all.