Ah cool. We're also moving over to docker internally, and we'll be looking deeper into upstreaming our pants integrations soon

our container is called pants-builder, it can build our monorepo

I'm planning a post on our setup once we get all the quirks solved

it's getting quite nice, monorepo with python, java, scala, go and node, dozens of services and every single one gets a CI pipeline and soon an opt-in CD

Yeah we'd be super interested in seeing your process. It sounds like we might be revamping our web stack internally soon as well

yeah - very intriguing - looking forward to the writeup

@red-cpu-25099 : whoa! just realized

./pants dep-usage ::

will find dead code

Would people generally prefer that release tags were prefixed with v to make tab completion work well vs branches? Ex: git co v1.<tab>

FYI: there is a problem when upgrading the version of pants to use the new style lock. If you run a new version of pants, it leaves behind a lock file that breaks old versions of pants:

2016-04-02 10:02:26,500: Regenerated BUILD files in 8.718 seconds.
*** Using BETA channel.  Unset SQPANTS_VERSION to use the stable channel.
Running Pants version square-20160329-01
INFO] Detected git repository at /Users/zundel/Development/java on branch zundel/jooq-generate-all-pants
Waiting on pants process None (/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python /Users/zundel/.cache/pants/bin/pants/pants-square-20160329-01.pex jooq topsawyer/topsawyer-model:jooq   ) to complete
Exception caught: (<class 'lockfile.AlreadyLocked'>)

Crud, I thought about this before but didn't catch it during the review.

This isn't going to fly for us when we upgrade, users switch back and forth between old and new branches. We just went through this with the error:

Exception message: [Errno 1] Operation not permitted: '/Users/pantsdev/Development/java/.pants.d/compile/zinc/252d64521cf9/testing-support.src.main.java.aux-lib/current'

and I'm still getting support queries about it. Once again,

./pants clean-all

seems to work around it for the global lock. I'm not sure about the ivy lock yet - testing.

Maybe this isn't as big of an inconvenience as the last time: Users will only see this when they switch back to an old branch, so it may not impact every pants users.

Crap, ./pants clean-all doesn't always fix it:

./pants clean-all
*** Using BETA channel.  Unset SQPANTS_VERSION to use the stable channel.
Running Pants version square-20160329-01
INFO] Detected git repository at /Users/zundel/Development/java on branch zundel/cake-eventstream

11:21:19 00:00 [main]
               See a report at: <http://localhost:60997/run/pants_run_2016_04_02_11_21_19_928_5cf3104e2537499d9963c0c1dc9c8be3>
11:21:19 00:00   [setup]
11:21:19 00:00     [parse]
               Executing tasks in goals: clean-allWaiting on pants process None (/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python /Users/zundel/.cache/pants/bin/pants/pants-square-20160329-01.pex clean-all  ) to complete

11:21:20 00:01   [complete]
               FAILURE
Exception caught: (<class 'lockfile.AlreadyLocked'>)

Exception message: /Users/zundel/Development/java/.pants.run is already locked

FYI @jolly-chef-92794 @brash-oxygen-26029 @bored-art-40741 ^^

@ancient-stone-50795 this won't affect the ivy lock. I knew this would happen with the run lock, but didn't consider a workflow switching back and forth

Easiest fix is to change the name of the new global lock, but it means you lose protection from two processes from before and after the change thrashing each other

@bored-art-40741: I personally am OK with that, but that may not reflect popular sentiment.

Oh. We could also fully delete the lock file when we're done with it

It's not guaranteed to work, but it will most of the time?

And it's also going to involve a race

Yeah, I thought about deleting the lock file. Wouldn't it be safe if you were holding the lock though?

Another possibility: we could have an option to change the name of the lockfile for uses in our situations (upgrading)

You cease to hold it once you delete it

But doing it at the end of release might be sad enough

Well, that's an OK thing to do right before release.

*safe

I like plumbing the lock name

If we had an option to change the name, then we'd have to be in the window of "two version of pants wont lock each other out" more than once.

It also nicely doesn't mess with the lock implementation, it just plumbs an option to context

Sort of trivially should be an option anyway