If we want to use the pex binary from python that isn’t 2.7 or 3.7, how are we meant to do so? If I run

./pex37

with 3.6 as my

python3

on my

PATH

it complains that

python3.7

couldn’t be found in the PATH…

1.6.1 is released: https://github.com/pantsbuild/pex/releases/tag/v1.6.1 https://pypi.org/project/pex/1.6.1/#files I'll be picking https://github.com/pantsbuild/pants/issues/6927 back up in the afternoon to upgrade Pants to it.

Would mind a review on this: https://github.com/pantsbuild/pex/pull/662 fixes an issue for pants/py3k. Thanks!

Although figuring out the issue here was a doozy, the fix was not bad in the end. Pex dynamic de-vendoring: https://github.com/pantsbuild/pex/pull/666

1.6.2 release prep: https://github.com/pantsbuild/pex/pull/667 https://github.com/pantsbuild/pex/issues/652

I have been wrapping my head around the codebase, and I think I found an issue with the way environments are handled in integration tests. In the following integration test:

def test_interpreter_constraints_honored_without_ppp_or_pp():
  # tox -e py35-integration -- -s -k test_interpreter_resolution_without_pex_python_path

  # Create a pex with interpreter constraints, but for not the default interpreter in the path.
  with temporary_dir() as td:
    py36_path = ensure_python_interpreter(PY36)

    pex_out_path = os.path.join(td, 'pex.pex')
    res = run_pex_command(['--disable-cache',
      '--interpreter-constraint===%s' % PY36,
      '-o', pex_out_path],
      env=make_env(
        PATH=os.path.dirname(py36_path),  # 3.6
        PEX_IGNORE_RCFILES='1'
      )
    )
    res.assert_success()

,

run_pex_command

calls

pex.py::main

, which reads environment variables from the global

ENV

instance of

Variables

. If I insert this call in the first line of `pex.py::main`:

print("BL: Running bin/pex.py::main(). ENV._environ.get('PEX_IGNORE_RCFILES') = {}, os.environ.get('PEX_IGNORE_RCFILES') = {}".format( ENV._environ.get("PEX_IGNORE_RCFILES"), os.environ.get("PEX_IGNORE_RCFILES")))

, I get:

BL: Running bin/pex.py::main(). ENV._environ.get('PEX_IGNORE_RCFILES') = None, os.environ.get('PEX_IGNORE_RCFILES') = 1

Should this be made into an issue along the lines of “Make sure we update

ENV

when running integration tests with custom envs”?

I think the main issue is trying to use

run_pex_command

instead of

run_simple_pex

. The former tries to be lighter weight, the latter is more robust.

I think, long term, killing

run_pex_command

is the way to go.

Hey! I have spent a bit of time working on https://github.com/pantsbuild/pex/pull/668. I believe it now has a good change and a test that fails in master and succeeds when the change is applied. However, I don’t see the travis dot running. What are the next steps?

@red-balloon-89377: i see the travis dot i think

1.6.4 release prep: https://github.com/pantsbuild/pex/pull/691 https://github.com/pantsbuild/pex/issues/681 This is yet more iteration to get pants CI green upgrading to pex 1.6.x.

hooray! thanks.

1.6.5 release prep: https://github.com/pantsbuild/pex/pull/697 https://github.com/pantsbuild/pex/issues/690

1.6.6 release prep: https://github.com/pantsbuild/pex/pull/702 https://github.com/pantsbuild/pex/issues/699

so, by default it's not supposed to be the case that a pex file will consume site-packages on someone's machine, right?

you'd have to pass

--inherit-sitepackages

?

(i should test this, sorry.)

Hey @enough-analyst-54434 and @witty-crayon-22786, I got all acceptance tests passing for reproducibility(!), except for the sdist test when ran specifically on PyPi. The Pex fails to build because it can’t resolve pycparser https://travis-ci.org/pantsbuild/pex/jobs/528583459#L841 Do you both agree that it would be fine to skip this test when using PyPi?

@hundreds-father-404: which PR is this referring to? sorry

re: https://github.com/pantsbuild/pex/pull/722: i feel pretty strongly that SOURCE_DATE_EPOCH is a misfeature when compared to them having specified a particular date that tools should use

I was not able to knock out https://github.com/pantsbuild/pex/issues/94 and I'll be OOO until next Thursday. @witty-crayon-22786 you should be able to release now though if you need to - you're a pex pypi maintainer. The process is described in https://github.com/pantsbuild/pex/blob/master/RELEASE.rst and the tracking issue is https://github.com/pantsbuild/pex/issues/704

ok, thank you sir.

would a note in the pants repo about how to edit

build-suppport/pants_venv

to add

-f

to the pip install line to use a development/from-source version of any of pants's dependencies be useful? where would that note be most useful to add?

@aloof-angle-91616: re https://github.com/pantsbuild/pex/issues/729: is there no solution possible by explicitly including a setuptools dep when depending on bigquery?

@witty-crayon-22786 It looks like pex 1.6.7 is missing the actual pex file; compare the assets for 1.6.7 and 1.6.6 on https://github.com/pantsbuild/pex/releases

Let’s see if I can work out how to fix this (and have permissions to)

Ok, I think I’ve just published a pex release?

huh who knew people wanted reproducible pex builds so badly https://github.com/pantsbuild/pex/pull/718#issuecomment-492345360

*cough

It seems that the way it is coded is not scalable, as you need to update it each time a new options is added. There should be a more generic way of passing any cli options down to pex.

Do we uh ask for him to submit a patch?