My todo list, from the top of my head (In descendi...
# development
c
My todo list, from the top of my head (In descending order of priority, time permitting and all that): • Proper dependency inference on lockfiles to be used with
--changed-since
• Better feedback on what changed after running
generate-lockfiles
(like diff locked versions etc) • Continue working on the Explorer.. • (Stretch) Revive the
visibility
feature PR (or re-design)
👍 2
w
[Rolls dice on
visibility
]
🤣 1
c
Bullet one is done for Python, pending is for the other ecosystems using lockfiles.. WIP on the second bullet.. here’s a teaser from my initial POC this weekend:
b
ooooohhh
If the dependency isn't direct, what about a flag to show how we got it? 😮
c
that would be cool… 🤔
dang, now I can’t not do it 😛
e
Are you aware that
pex3 lock update
gives this info?
👀 1
c
no, thanks will look at that 🙂
oh, which part btw, the what versions where changed, or why a certain dist is in the lockfile?
Ah, noticed this output:
Copy code
Updates for lock generated by universal
  Updated flask from 2.2.2 to 2.1.3
guess that answers it 🙂
e
Which versions are changed. There are several things going on here, so you may just have to make progress and then circle back, but: + The Pex lockfile format is not public, fully subject to change, Pex can break you here. + Pants use of
lock create
is not the way to update lock files, it should use `lock update`and that opens up targetd updates with
-p
later - like cargo. + Pants should define a dependency graph format. That's the way to get why answers for all resolvers - coursier, pex, etc... See: https://github.com/pantsbuild/pex/issues/1137 https://github.com/pantsbuild/pants/issues/13283
For the dependency graph, see discussion here: https://github.com/pantsbuild/pex/pull/1132
c
Cool, thanks! 👍
regarding pex lockfile format being private, I guess one way around that is to rely on
pex lock export
.. unless all this would be more tightly integrated in Pants.. one side I kind of liked with a dedicated external tool is that it opens up a little more customizations/flexibility on the user side of things when it’s not deeply buried in Pants. That may not be the best approach though.. ?
e
I really think dancing around Pants actually picking a format has gone on too long. It should do so and publish it. Pex will then export to that.
👍 1
But yes, agreed, that would work today.
c
Regarding
pex graph
that works on a built pex file only, right? No way to get the graph data off of a lockfile (or named dist without building a pex file) only?
e
Correct. The PEX_TOOL tools only work on PEX files and preceeded
pex3 <subcommands>
. That would be good to move to
pex3
. At some point every PEX file will embed a lockfile to slightly speed up cold boots. Right now there are 2 runtime resolvers in Pex, the lockfile resolver that resolves a subset from a lockfile and the PEX repository resolver that resolves a subset from a PEX. Their logic should merge as should their tool support.
👍 1