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

    rough-dog-96241

    04/11/2017, 10:22 PM
    The directory in .pants.d that pants chooses to use for a valid target corresponds to the sha1 of the cache key. In order to point at an "old" but valid cache key, I'm guessing it is supposed to point the 
    current
    symlink 'back' to the old directory but never does. Sounds like you think I'm insane, so I'm going to fish through 
    cache_manager.py
    and see what I can find.
  • w

    witty-crayon-22786

    04/11/2017, 10:24 PM
    it is never supposed to reuse an old directory. it deletes/clears the directory before giving it to the task in the invalidated block.
  • w

    witty-crayon-22786

    04/11/2017, 10:24 PM
    again: if it hits the cache, that will usually look like we reused an old directory.
  • r

    rough-dog-96241

    04/11/2017, 10:28 PM
    Okay. Fair enough. It looks like it only creates the "current" symlink for invalid VT's, though: https://github.com/pantsbuild/pants/blob/1.2.x/src/python/pants/invalidation/cache_manager.py#L196-L199
  • w

    witty-crayon-22786

    04/11/2017, 10:31 PM
    iirc, all VTs start out invalid, and then after hitting the cache may become valid before the invalidated block
  • w

    witty-crayon-22786

    04/11/2017, 10:31 PM
    so presumably that's called before checking the cache.
  • r

    rough-dog-96241

    04/11/2017, 10:47 PM
    @witty-crayon-22786 -- If I just rm .pants.d and don't rm the cache the problem fixes itself (and it creates the directory correctly). I'm on pants 1.2.x, and I wonder if this issue is fixed with these changes of mateo's that seem to blow away the results dir every time.
  • w

    witty-crayon-22786

    04/11/2017, 10:47 PM
    1.2.x or 1.2.1
  • r

    rough-dog-96241

    04/11/2017, 10:47 PM
    1.2.1
  • r

    rough-dog-96241

    04/11/2017, 11:35 PM
    @witty-crayon-22786 I seem to have solved my braindamage by replacing my uses of 
    vt.results_dir
    with 
    vt.current_results_dir
    -- the former is a symlink which doesn't update if the target is valid, the latter is generated from the cache key and works.
  • g

    gray-sugar-70433

    04/12/2017, 4:37 AM
    Hey guys, what are the best practices for stuff that needs to modify the source tree? Such as running go-fmt, putting generated files/documentation in vcs, etc. Should I use 
    make
    side by side with pants?
  • g

    gray-sugar-70433

    04/12/2017, 4:37 AM
    Or is there a better option?
  • p

    purple-oil-45048

    04/12/2017, 7:48 AM
    So I am thinking of a migration strategy to adopt pants from an sbt multi-project setup
  • p

    purple-oil-45048

    04/12/2017, 7:48 AM
    Has anyone done something similar in the past?
  • p

    purple-oil-45048

    04/12/2017, 7:53 AM
    Our corrent structure is
    Copy code
    + /foo
          /src/main/scala
              /test/scala
+ /bar
          /src/main/scala
              /test/scala
    As a first step, I wanted to make 
    ./pants test ::
    work. But as far as I understand, pants would like to have all tests under 
    /test
    — which isn’t the case yet..
  • p

    purple-oil-45048

    04/12/2017, 8:05 AM
    So my first attempt was to 
    ln -s foo/src/main/scala src/scala/foo
    but pants doesn’t seem to like symbolic links: 
    Exception message: Can only scan directories and src/scala/foo is not a valid dir
  • p

    polite-student-85192

    04/12/2017, 12:33 PM
    I have a prep_command, goal='test', that lists some jvm_binary targets in its dependencies. The binaries don't get generated when I execute the corresponding tests. Surprising? Trying to test an IntelliJ plugin and I need to build some jars and shuffle them around on disk to locations IntelliJ expects.
  • b

    bright-apartment-76721

    04/12/2017, 3:21 PM
    can I just tell pants to use a folder full of unmanaged jars when running/building/etc.?
  • c

    clean-fish-15260

    04/12/2017, 4:00 PM
    @purple-oil-45048 I migrated us out of a pretty similar setup
  • c

    clean-fish-15260

    04/12/2017, 4:01 PM
    I actually did tests last
  • c

    clean-fish-15260

    04/12/2017, 4:02 PM
    I left the SBT machinery in place and dropped in pants alongside it, adding 
    pants
    and 
    pants.ini
    to the root of the repo, 
    3rd-party
    , 
    build-support
    , etc
  • c

    clean-fish-15260

    04/12/2017, 4:03 PM
    then all the 
    BUILD
    files, and I strongly recommend you try to use the buildgen for scala from fsq.io
  • c

    clean-fish-15260

    04/12/2017, 4:03 PM
    sbt will ignore all of this so you can cut over pretty gradually
  • w

    witty-crayon-22786

    04/12/2017, 4:31 PM
    @purple-oil-45048 : all of the tests do not need to be under `tests`: generally they should be under a "source root" pattern: http://www.pantsbuild.org/setup_repo.html#source-roots ... but even that isn't a strict requirement for tests, because their package name doesn't really matter
  • w

    witty-crayon-22786

    04/12/2017, 4:31 PM
    your current structure already matches the default patterns... see 
    ./pants help-advanced source
    for more info.
  • w

    witty-crayon-22786

    04/12/2017, 4:33 PM
    @bright-apartment-76721 : not really... except to the extent that ivy supports that.
  • w

    witty-crayon-22786

    04/12/2017, 4:33 PM
    in particular, you need to be able to find poms
  • w

    witty-crayon-22786

    04/12/2017, 4:34 PM
    and that requires ivy patterns
  • b

    bright-apartment-76721

    04/12/2017, 4:34 PM
    ah 😕
  • w

    witty-crayon-22786

    04/12/2017, 4:35 PM
    if things are fatjars, recent versions of pants support relative urls: 
    jar(name, org, rev, url='<file://this/is/a/relative/path>')
    ... to support checking things into the repo if that floats your boat
1...170417051706...2420Latest