pantsbuild #development

Channels

welcome

github-notifications

development

witty-crayon-22786

07/13/2016, 4:09 AM

in particular, they were used to convert to git patterns for use with git sparse checkout: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7

witty-crayon-22786

07/13/2016, 4:10 AM

i think that if we have so far been able to get the entire twitter repo working with regard to

**

working in a way that matches git, we should prefer to match git (rather than twitter.commons, which is not sufficiently popular to be considered a standard)

billowy-beach-68498

07/13/2016, 4:10 PM

I see. thanks for the info! yeah, I agree we should match git convention

rough-minister-58256

07/14/2016, 6:30 PM

@billowy-beach-68498: ok to land https://rbcommons.com/s/twitter/r/4057/ now? CI just went green

rough-minister-58256

07/14/2016, 6:56 PM

(ok for me to land/commit on your behalf, I mean)

rough-minister-58256

07/14/2016, 7:00 PM

assuming so

billowy-beach-68498

07/14/2016, 7:47 PM

yeah I think so

billowy-beach-68498

07/14/2016, 7:48 PM

ah you have landed for me, thanks!

rough-minister-58256

07/14/2016, 8:01 PM

rough-minister-58256

07/15/2016, 6:49 PM

nice, successfully requested and received an API change from the pathspec guy: https://github.com/cpburnz/python-path-specification/issues/11

witty-crayon-22786

07/15/2016, 8:13 PM

an excellent sign

ancient-stone-50795

07/16/2016, 1:05 AM

I wish I could offer some help with the engine but I can't 😞

witty-crayon-22786

07/18/2016, 7:12 PM

it occurs to me that while we've been focused on bootstrap/codegen, there is another component that we could begin porting, which doesn't have nearly so many dependencies

witty-crayon-22786

07/18/2016, 7:12 PM

the python backend

rough-minister-58256

07/18/2016, 7:14 PM

I’d personally love to port that, but I’d question the overall impact it’d make

rough-minister-58256

07/18/2016, 7:14 PM

in terms of our users etc

rough-minister-58256

07/18/2016, 7:15 PM

also, bootstrap could potentially be huge

witty-crayon-22786

07/18/2016, 7:15 PM

yea. primary advantage i see is just that it's a real usecase that could be completed end to end

rough-minister-58256

07/18/2016, 7:15 PM

yeh definitely

rough-minister-58256

07/18/2016, 7:15 PM

I wonder if it’d make sense

rough-minister-58256

07/18/2016, 7:15 PM

to approach that entire thing in a bazel-like way

rough-minister-58256

07/18/2016, 7:15 PM

e.g. interface with pex via CLI vs code

rough-minister-58256

07/18/2016, 7:16 PM

treat all calls to pex as subprocess execution of the pex cli, which we bootstrap via pants etc

rough-minister-58256

07/18/2016, 7:17 PM

imo, engine-based-bootstrap has far reaching benefits

rough-minister-58256

07/18/2016, 7:17 PM

had a thought over the weekend re: engine UI stuff

rough-minister-58256

07/18/2016, 7:19 PM

was thinking that we could actually designate special output channels in an extension of the nailgun protocol for engine outputs - so in the pailgun context we could emit “backchannel” messages that’d basically be like watching the console for “engine worker 1” etc

rough-minister-58256

07/18/2016, 7:19 PM

stdout, stderr, engine_worker_1, engine_worker_2, …, engine_worker_N

rough-minister-58256

07/18/2016, 7:19 PM

then separate the presentation of that in the nailgun client

witty-crayon-22786

07/18/2016, 7:20 PM

just forking a process for pex would be good probably, yea.

rough-minister-58256

07/18/2016, 7:20 PM

yeh it’d be nice to decompose pex in a way that would allow for that