...will mark.

oh, thanks!

that'll be super helpful, so I don't need to maintain a weird ad-hoc patch on top of the version my team uses 🙂 thanks

the 1.3.1 release isn't actually scheduled right now, but there is an actual queue of issues there, so we probably ought to get on that.

okay, I'm definitely not in a rush (as I said, I do have the weird patch thing working :))

@happy-kitchen-89482: @wide-energy-11069 has been working with a contributor on https://github.com/pantsbuild/pants/pull/4921... one of the issues they've encountered is that the library it uses (

buildifier

?) assumes that targets have names

obviously i'd like to preserve the ability to have an implicit name for a target, as it really does help encourage 111

but the issue seems to be that without having a symbol table that knows which symbols represent targets (and which don't), you can't determine which no-name function call in a BUILD file owns the default name

there are other heuristics you can use, such as requiring that it be a top-level (and thus sideeffecting) method call?

cc @wide-energy-11069: ^

Has anybody looked in to writing a continuous build plugin? If not, is such a thing possible? I’m thinking about making one. My day-to-day workflow is read->modify->compile->repeat. The feedback loop from compiler errors is enormously useful.

we've (Twitter) thought about it, but delayed starting it until after the daemon is stabilized: https://www.pantsbuild.org/invoking.html#the-pants-daemon

in particular, the daemon incorporates watchman below new filesystem monitoring infrastructure, so a design that uses that infrastructure would be pretty different (much easier/more accurate) than one that didn't

👍 Do you know of a simple workaround I can do for now? I’d rather not go off and write a thing with something like that in the works.

./pants filedeps $target

+ a CLI file monitoring tool should be sufficient to hack up a script.

Cool. sounds good

@happy-kitchen-89482: i've overhauled https://github.com/pantsbuild/pants/pull/4635 to make it much cheaper (optional classpath dependency and compiler plugin) and move it out of

contrib

and into core... mind taking another look

Sure

arguably both scalafix and scalafmt could go in contrib, but since scalafmt was already in core, preserving the status quo made sense.

can someone help to review this PR https://github.com/pantsbuild/binaries/pull/44 ?

thansk

s/thansk/thanks

@brash-cricket-7489: quick comment

(...added there)

@brash-cricket-7489: there is still a yarn i386 package in there

@witty-crayon-22786 good catch

@brash-cricket-7489: merged and synced

Hi everyone! We are using pants in our project and faced some really weird issue that we can't resolve. The pants version that we are using is 1.2.0 and everything used to work ok. But today when I tried to checkout project from scratch and run pants there - the following happened:

**** Failed to install cryptography-2.1 (caused by: NonZeroExit("received exit code 1 during execution of `['/Users/kirach/.cache/pants/setup/bootstrap-Darwin-x86_64/pants.C0R0Ok/install/bin/python2.7', '-', 'bdist_egg', '--dist-dir=/var/folders/bz/cggbqdrn4wd8n6l310rzlg4c0000gn/T/tmpVBwZdC']`",)
):
....
cffi.api.CDefError: cannot parse "typedef int __dotdotdot__  time_t;"
:24:28: before: time_t
...

Exception message: Package SourcePackage(u'file:///Users/kirach/.cache/pants/plugins/cryptography-2.1.tar.gz') is not translateable by ChainedTranslator(EggTranslator, SourceTranslator)

I have the full output here: https://gist.github.com/kiRach/9f0cdeb4bbadf2a2d388e1d2bd58865f

One of my colleagues also tried to remove his

~/.cache/pants

and run pants again - and faced the same issue