https://pantsbuild.org/ logo
Powered by
#general
  • r

    rough-minister-58256

    11/05/2015, 12:43 AM
    hmm, is there a workaround for the issue of a stray BUILD.md landing in your working copy nad breaking pants? something to do with excludes?
  • m

    mammoth-pharmacist-54215

    11/05/2015, 12:43 AM
    running that in our repo creates a huge tar.gz file.
  • w

    witty-crayon-22786

    11/05/2015, 12:58 AM
    @bored-art-40741: how would you guys feel about requiring actual jar copies into 
    .pants.d/ivy/jars
    , rather that symlinks?
  • b

    bored-art-40741

    11/05/2015, 1:04 AM
    For what purpose?
  • b

    bored-art-40741

    11/05/2015, 1:05 AM
    And perhaps more importantly--does that apply only to ivy, or to anything that produces jar classpath products? (i.e. our custom resolver)
  • b

    bored-art-40741

    11/05/2015, 1:05 AM
    On the one hand, I'd prefer to keep .pants.d portable and not too bloated (many users have several checkouts, and so do CI machines)
  • b

    bored-art-40741

    11/05/2015, 1:05 AM
    OTOH I don't care too much about what ivy does provided it doesn't interfere with pom-resolve
  • b

    bored-art-40741

    11/05/2015, 1:06 AM
    I suppose copies of jars are indeed more portable than symlinks
  • l

    limited-country-20626

    11/05/2015, 1:06 AM
    we could then really just run stuff from user’s repro tar files
  • r

    red-cpu-25099

    11/05/2015, 1:23 AM
    Does anyone NOT use nailgun for zinc?
  • w

    witty-crayon-22786

    11/05/2015, 1:23 AM
    @bored-art-40741: i think we had discussed it in the past for the purposes of stabilizing things even if the user's ivy directory is cleared
  • w

    witty-crayon-22786

    11/05/2015, 1:24 AM
    but in this case, it means that canonicalizing the classpath is stable
  • w

    witty-crayon-22786

    11/05/2015, 1:25 AM
    Copy code
    we could then really just run stuff from  user’s repro tar files
    oo, yea.
  • r

    red-cpu-25099

    11/05/2015, 1:30 AM
    A little bit context for previous question: I'm going to remove one old fix for some too-long-args issue because this fix is issue now and everything works just well with nailgun. So interesting case is not compiling with nailgun = off, but compiling a lot of code in long-long-named directories with nailgun = off.
  • l

    limited-country-20626

    11/05/2015, 1:44 AM
    @red-cpu-25099: I think in that case if someone was compiling and came across the too-long args they could choose between enabling the nailgun or to use the option implementated by peiyu that puts run_java ’s classpath in a singleton jar. But I am curious what is the impetus to remove the "old fix"?
  • r

    red-cpu-25099

    11/05/2015, 1:59 AM
    @limited-country-20626: Peiyu's solution works well for classpath, but not for arguments. In this case we provide compiling classpath as argument to zinc compiler, not as classpath itself for zinc compiler. Old fix relativize everything to buildroot, in case of workdir outside of buildroot it comes to be a path with ../, and zinc compiler doesn't handle this very well.
  • a

    ancient-stone-50795

    11/05/2015, 7:16 PM
    @rough-minister-58256: we use sentry at square too.
  • r

    rough-minister-58256

    11/05/2015, 7:16 PM
    oh nice - for pants?
  • a

    ancient-stone-50795

    11/05/2015, 7:17 PM
    No, not for pants, for everything else. It might be nice to report exceptions to sentry though. Right now if someone hits an exception they have to repeat it for me.
  • r

    rough-minister-58256

    11/05/2015, 7:17 PM
    ah yeah exactly our problem
  • r

    rough-minister-58256

    11/05/2015, 7:18 PM
    would make our releases significantly easier
  • r

    rough-minister-58256

    11/05/2015, 7:18 PM
    imho
  • a

    ancient-stone-50795

    11/05/2015, 7:18 PM
    Does anyone have a Java version of a 
    prep_command()
    ? I mean specify a jvm_binary to run and pass arguments to it. It should be simple, I've queue it up internally.
  • w

    witty-crayon-22786

    11/05/2015, 7:18 PM
    @ancient-stone-50795: if it's java, why not have it as a test base class?
  • a

    ancient-stone-50795

    11/05/2015, 7:19 PM
    We've got a database migration step that we've been using 
    maven-exec-plugin
    for. I've replaced it with a 
    prep_command()
    but it is slow because it has to re-invoke pants 
    ./pants binary ...
  • a

    ancient-stone-50795

    11/05/2015, 7:20 PM
    @witty-crayon-22786: that's a good point, but its not setup that way now. Its a command that gets run during deployment. For testing, some projects re-use it to setup several test databases with the same command.
  • w

    witty-crayon-22786

    11/05/2015, 7:24 PM
    prep_command was sortof a dirty hack when we implemented it
  • w

    witty-crayon-22786

    11/05/2015, 7:24 PM
    (still is)
  • a

    ancient-stone-50795

    11/05/2015, 7:25 PM
    I think this is kind of a dirty hack too. I thought about making a specific (migration) target, but it would just be a matter of passing down args to generalize it.
  • w

    witty-crayon-22786

    11/05/2015, 7:25 PM
    i wouldn't block it, but for more perspective:
1...676677678...2420Latest