Is there a way to have pants generate a lock file ...
# general
f
Is there a way to have pants generate a lock file that includes the dependencies for "listed"
platform_systems
? context: • we have python libraries in out monorepo that are build and deployed on both Windows and Linux for some transitive dependencies, if the
platform_system
is Windows, then there are "extra" dependencies required. however, i notice that the .lock files, generated via Linux, do not have these extra artifacts included, when built on linux. example -
bpython
if it's windows, the dependency tree looks like (curtesy poetry)
Copy code
bpython 0.24
├── curtsies >=0.4.0
│   ├── blessed >=1.5 
│   │   ├── jinxed >=1.1.0    <------------ Windows only
│   │   │   └── ansicon * 
│   │   ├── six >=1.9.0 
│   │   └── wcwidth >=0.1.4 
│   └── cwcwidth * 
├── cwcwidth *
├── greenlet *
├── pygments *
├── pyxdg *
└── requests *
    ├── certifi >=2017.4.17 
    ├── charset-normalizer >=2,<4 
    ├── idna >=2.5,<4 
    └── urllib3 >=1.21.1,<3
jinxed
is only for Windows (Windows - extras for curses terminal handling) How do I tell
generate-lockfiles
to include the windows dependencies, when built on linux ?
I don;t think this has hit us before (assumption) because the "wheel" delivered to the Windows machines, are doing the final transitive dependency of the unwritten ones but this does mean we have unknowns I see in our pants vs a poetry generated lockfile 5 such libraries that are Windows specific transitive's
b
I think the underlying pex tool https://docs.pex-tool.org/index.html supports generating lockfiles in configurations other than “Mac and Linux”, but pants may not expose it. So, options (not mutually exclusive): • file a feature request for controlling the platforms a lockfile is generated for • Generate the lockfile pants uses with
pex3 lock create
directly rather than via pants, and set https://www.pantsbuild.org/2.19/reference/subsystems/python#resolves_generate_lockfiles
f
If i was to go down this route, is there a way to ask pants for the path (in the cache) to the
pex
binary. we currently don't deploy pex to our developer machines separately. running
--level=debug
shows me where it is 😄 but parsing a fake pex call will be complicated.
Copy code
{ argv: ["/home/user8/.cache/nce/260e9f180e257368873660af8dd93ef1ae670cb61bde99eea1fd914ad6e534bb/bindings/venvs/2.19.0/bin/python3.9", "./pex", "lock", "create", "--tmpdir", ".tmp", "--python-path", "/home/user8/projects/svcs.com/group99/se/core/lib/knohh/.venv/bin:/home/user8/.pyenv/plugins/pyenv-virtualenv/shims:/home/user8/.pyenv/shims:/home/user8/.pyenv/bin:/home/user8/.local/bin:/home/user8/.cargo/bin:/home/user8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin", "--output=lock.json", "--no-emit-warnings", "--style=universal", "--pip-version", "23.1.2", "--resolver-version", "pip-2020-resolver", "--target-system", "linux", "--target-system", "mac", "--indent=2", "--no-pypi", "--index=<https://svcs.com/api/v4/groups/group99/-/packages/pypi/simple/>", "--manylinux", "manylinux2014", "--interpreter-constraint", "CPython<3.11,>=3.10", "autopep8==2.0.4", "black==23.10.1", "flake8==6.1.0", "numpy==1.26.2", "opencv-contrib-python==4.8.1.78", "pre-commit==3.5.0", "pylint==3.0.2", "pyqt5-qt5==5.15.2", "pyqt5==5.15.7", "pytest==7.3.1", "wheel==0.41.3"], env: {"CPPFLAGS": "", "LANG": "en_AU.UTF-8", "LDFLAGS": "", "PATH": "/home/user8/projects/svcs.com/group99/se/core/lib/knohh/.venv/bin:/home/user8/.pyenv/plugins/pyenv-virtualenv/shims:/home/user8/.pyenv/shims:/home/user8/.pyenv/bin:/home/user8/.local/bin:/home/user8/.cargo/bin:/home/user8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin", "PEX_IGNORE_RCFILES": "true", "PEX_PYTHON": "/home/user8/.cache/nce/260e9f180e257368873660af8dd93ef1ae670cb61bde99eea1fd914ad6e534bb/bindings/venvs/2.19.0/bin/python3.9", "PEX_ROOT": ".cache/pex_root", "PEX_SCRIPT": "pex3"}, working_directory: None, input_digests: InputDigests { complete: DirectoryDigest { digest: Digest { hash: Fingerprint<b6e56f4c75927cccecc95b60f6c243aebd057381544b45bee674fc07cbe23dec>, size_bytes: 158 }, tree: "Some(..)" }, nailgun: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, inputs: DirectoryDigest { digest: Digest { hash: Fingerprint<b6e56f4c75927cccecc95b60f6c243aebd057381544b45bee674fc07cbe23dec>, size_bytes: 158 }, tree: "Some(..)" }, immutable_inputs: {}, use_nailgun: {} }, output_files: {RelativePath("lock.json")}, output_directories: {}, timeout: None, execution_slot_variable: None, concurrency_available: 0, description: "mock_ae lockfile for python-alaf", level: Info, append_only_caches: {CacheName("pex_root"): RelativePath(".cache/pex_root"), CacheName("python_build_standalone"): RelativePath(".python-build-standalone")}, jdk_home: None, cache_scope: PerSession, execution_environment: ProcessExecutionEnvironment { name: None, platform: Linux_x86_64, strategy: Local }, remote_cache_speculation_delay: 0ns, attempt: 0 }
b
I don’t think it’s easy to get to pants’ internal pex, but it’s possible to install one’s own. For instance, a
python_requirements(name=“pex”, requirements=[“pex==2.2.1”], resolve=“pex-cli”)
. This can then be run with
pants run path/to:pex
. I recommend put it in a dedicated resolve, because it’s just a binary not something your actual code needs to import.
👍 1