#general
- c
curved-manchester-66006
05/09/2017, 8:28 PMWell, manually vendoring was a practice that I found particularly concerning - l
limited-country-20626
05/09/2017, 8:31 PMit is far superior to the old python backend - l
limited-country-20626
05/09/2017, 8:31 PMthe main problem with the Go backend, imo - l
limited-country-20626
05/09/2017, 8:32 PMis that it doesn’t have an invested party that is keeping it current with the rapid pace of Go development - l
limited-country-20626
05/09/2017, 8:33 PMand B) resistance from Go users who resent the pants overhead - l
limited-country-20626
05/09/2017, 8:33 PMwhich is ~relatively light, but certainly legitimate - h
happy-kitchen-89482
05/09/2017, 8:40 PMWe’ve integrated the go backend - h
happy-kitchen-89482
05/09/2017, 8:41 PMIt’s just two of us, and we’re not developing intensively in Go, but so far no complaints about the overhead - h
happy-kitchen-89482
05/09/2017, 8:42 PMAnd Pants does solve the vendoring problem well, and also gives us a uniform build process - h
happy-kitchen-89482
05/09/2017, 8:42 PME.g.,
runs all our tests, not “all our tests except for Go, which we have to remember to run separately”./pants test :: - h
high-advantage-47550
05/09/2017, 8:56 PMhave you had any reports that pants is slow/slower on sierra vs el capitan? - h
happy-kitchen-89482
05/09/2017, 8:57 PMThe main pain point for us right now is actually in the underlying tooling, namely that
doesn’t build tests, sogo build
has to first invoke the compiler to run tests, and it does this every time.go test - h
happy-kitchen-89482
05/09/2017, 8:57 PM@high-advantage-47550 I’ve not heard such reports, no. Are you seeing this? - h
high-advantage-47550
05/09/2017, 8:58 PMa couple people on my team mentioned that they noticed it felt slower (no hard data) after upgrading to sierra - h
high-advantage-47550
05/09/2017, 8:58 PMcould just be a coincidence, just wanted to check 🙂 - h
high-advantage-47550
05/09/2017, 8:59 PMcould be that our required antivirus acts differently on each version - r
rough-dog-96241
05/09/2017, 9:57 PMI'm trying to figure out why the unused checker is complaining -- do you have to use all the jar()s in a jar_library() for it to be considered "used" or just one of them? - w
witty-crayon-22786
05/09/2017, 11:23 PM@rough-dog-96241 : should just be one. but if it's a dependency, ie
then it's not exportedjar_library(.., dependencies=['xx']) - w
witty-crayon-22786
05/09/2017, 11:24 PMbut also, unfortunately, the unused check has a lot of false positives =/ - r
rough-dog-96241
05/09/2017, 11:24 PM😞 K - w
witty-crayon-22786
05/09/2017, 11:30 PMBUT there is a scalac plugin that supports unused dep detection. we haven't experimented with it yet, but - w
witty-crayon-22786
05/09/2017, 11:36 PM@fancy-queen-20734 : so... the result of an ivy resolve is the complete graph of versions, yea? - w
witty-crayon-22786
05/09/2017, 11:36 PMincluding the versions that weren't selected? - w
witty-crayon-22786
05/09/2017, 11:37 PM(not the fetching, just the resolve) - f
fancy-queen-20734
05/09/2017, 11:37 PMhm. I don’t think it retains all of that by default right now - w
witty-crayon-22786
05/09/2017, 11:37 PMit's in the rendered report - f
fancy-queen-20734
05/09/2017, 11:37 PMI had a theory that I could partition resolves by conf to map the build graph into the resolve graph but …. - w
witty-crayon-22786
05/09/2017, 11:37 PMyea, i was just having that same feeling - f
fancy-queen-20734
05/09/2017, 11:37 PMyeah, I think there’s information about which versions were seen - w
witty-crayon-22786
05/09/2017, 11:38 PMwe have the complete graph in the xml generated during./pants resolve.ivy --open