Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

I think if we moved the options_bootstrapper and working_set passing to GoalRunner.__init__() it’d let us clean up much of the initialization code that now happens outside of __init__()

then GoalRunner(options_bootstrapper, working_set, root_dir) would setup all of the options and instance attributes - then .setup() would be more normal

not sure if there were ever plans to have multiple .setup() invocations in the same run, but as the code stands today doesn’t seem necessary

is anyone aware of an open source, built in or otherwise canonical way to create a virtualenv from the set of dependencies for a python pants target?

this is more for development, especially for something like flask with an autoreloader

if you use `pants run` or `pants repl`, internally it'll make a venv with your target + all of its deps

i think my ideal is something that would dump deps and generated code to disk either as a virtualenv or as wheels but make it easy for me to run/edit code; i was thinking of building a task that basically did that but i just wanted to make sure no one else already had

right now i just do—roughly—./pants dependencies --external-only &lt;target&gt; | xargs pip install

Yeah, I think I see. Because the JVM requires a compile, it's natural for JVM developers to 1. code change 2. compile 3. run 4. repeat

but for interpreted languages, it would be nicer to simplify that

<@U083H6LRL>: We wrote this, we're waiting on upstream changes to pip to merge it into contrib

If you're curious for a preview or want to crib: <https://rbcommons.com/s/twitter/r/2482/>

A lot of code there is to make it executable

But at its core it's just a way to bundle a python_binary into a self-bootstrapping virtualenv

<@U083H6LRL>: the venv that pants creates for run/repl

&gt;&gt;&gt; sys.path
['/Users/areitz/workspace/pants/.pants.d/python-setup/chroots/55f13819f42a319be4a1825009e2ef841d656b31/.bootstrap', '/Users/areitz/workspace/pants/.pants.d/python-setup/chroots/55f13819f42a319be4a1825009e2ef841d656b31', '/Users/areitz/workspace/pants/src/python',```

so if you are doing `pants run` of a target that launches a web server

and then you modify some of your app server code in the repo

Chroots are just unzipped pexes, I thought

<@U06A02Y4T>: i didn't know that, i thought it would've copied in things

<@U053HNE90>: isn't a PEX just a zipped virtualenv?

Release RB: <https://rbcommons.com/s/twitter/r/2661/>

A PEX is its own kind of format with its own tricks to isolate it from the parent interpreter