#pex
- e
enough-analyst-54434
10/11/2018, 8:32 PMI have not seen this one. That said - I no longer see any reason for pex to support a wide range of setuptools. 1. At build-time we setup an interpreter cache with a setuptools that affects no-one but pex. 2. At runtime we use the vendored bits we need and push them to the back of sys.path now before running user code👍 1 - e
enough-analyst-54434
10/11/2018, 8:33 PMWould pinning our version make sense? We really need to for py3.7 for example - which fails without new setuptools to handle eggs. - e
enough-analyst-54434
10/11/2018, 8:34 PMThe only reason I can see pinning would be bad if folks using pex with no internet connection - which may be a thing. IE: they want pex to use local -f repos for all deps, etc. and those local sources only have old setuptools. - e
enough-analyst-54434
10/11/2018, 8:39 PMVendoring setuptools and wheel in the pex dist (as opposed to small bits of setuptools vendored into generated pexes, which we'd still need) is probably the right thing to do. This would allow full control in lights-out situations at the cost of the dist size. - h
hundreds-father-404
10/11/2018, 9:02 PMI don’t know enough about PEX to really know what I’m talking about, but that sounds reasonable to me John. In general, as much as we can simplify our core assumptions—eg the setuptools version—the easier it will be for us to keep PEX robust and futurized - r
rough-minister-58256
10/11/2018, 10:59 PMI think the range pin still makes sense for the general global transitive case of pex co-existing with other deps? - r
rough-minister-58256
10/11/2018, 11:01 PMbut maybe it would make sense to vendor an exact setuptools version in pex itself and then drop its own install_requires dep on setuptools? - r
rough-minister-58256
10/11/2018, 11:02 PMthat might solidify bootstrap code to operate against an internal fixed version of setuptools for the purposes of pex runtime - then be agnostic to whatever the env provides - r
rough-minister-58256
10/11/2018, 11:02 PMaccomplishing effectively the same thing w/o transitive impact - r
rough-minister-58256
10/11/2018, 11:05 PMit may go deeper than that tho? - r
rough-minister-58256
10/11/2018, 11:15 PMbut if possible, would nicely compartmentalize in pex itself vs relying on pants interpreter setup to handle that concern - r
rough-minister-58256
10/11/2018, 11:29 PMwould be less forgiving at runtime tho (i.e. bumps to that version would require a release) - but would ensure a consistent setuptools in e.g. pex CI as coverage measuree- 2
- 2
- w
witty-crayon-22786
10/18/2018, 5:09 PMno pex references, but helpful: http://andrewsforge.com/article/python-new-package-landscape/😩 1 - a
average-vr-56795
10/19/2018, 1:23 PMDo we expect
to propagate through the underlying exit code of the process it invokes?pex - a
average-vr-56795
10/19/2018, 1:24 PMRunning
shows the failure but exits 0, whereas invoking pytest directly with python has the same output but exits 1~/Downloads/pex27 -D failing_test -e pytest:main pytest - h
hundreds-father-404
10/19/2018, 1:33 PMThis exact question was the cause of my project’s CI always being green (I’m using custom build scripts). I settled on the solution to pass a flag
if I want it to propagate or not.—ci - a
average-vr-56795
10/19/2018, 1:40 PMAs in, you hacked around it? Or you found some flags you can pass to pex to make things work as you want? - a
average-vr-56795
10/19/2018, 1:42 PM(If the former, how does your hack work? If the latter, what magic flags? 😄) - a
average-vr-56795
10/19/2018, 1:45 PMI think I see the problem… 😄 - a
average-vr-56795
10/19/2018, 1:58 PM - a
average-vr-56795
10/19/2018, 2:17 PMI think the CI failures on ^^ are exposing that our tests are currently silently failing, rather than that my change is bad. So that’s fun.e- 2
- 1
- h
hundreds-father-404
10/19/2018, 2:51 PMSorry I mean I wasn’t using PEX. I was just using my own build scripts and had a similar problem that my script wasn’t propagating errors. I chose to fix that problem by allowing a command line flag that turns on propagation - h
hundreds-father-404
10/19/2018, 2:53 PMI think for PEX, it would make sense that we propagate by default (principle of least surprise) and allow a flag line —return0 to trigger this back off. A lot of CI tools behave that way / have a similar flag - a
average-vr-56795
10/19/2018, 4:00 PM@enough-analyst-54434 Thanks for the review and fixes! I’ll let you merge your fix, then rebase mine atop - a
average-vr-56795
10/19/2018, 5:41 PM@enough-analyst-54434 I think my test is failing because its pwd is in the pex dir; I repro the failure if I run the command in the pex working dir, but the command line succeeds if I run it from the tempdir - a
average-vr-56795
10/19/2018, 5:41 PMAny idea how to fix? - a
average-vr-56795
10/19/2018, 5:42 PM(I’ve yet to successfully run just one test with tox, so iterating is pretty painful) - e
enough-analyst-54434
10/19/2018, 5:42 PMHuh - ok - e
enough-analyst-54434
10/19/2018, 5:42 PM./dtox ? - e
enough-analyst-54434
10/19/2018, 5:42 PMI had set that up a while ago