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

    witty-crayon-22786

    06/05/2017, 9:19 PM
    Copy code
    gen.protoc.supportdir = bin/protobuf (from HARDCODED)
gen.ragel.supportdir = bin/ragel (from HARDCODED)
go-distribution.supportdir = bin/go (from HARDCODED)
native-engine.supportdir = bin/native-engine (from HARDCODED)
node-distribution.supportdir = bin/node (from HARDCODED)
thrift-binary.supportdir = bin/thrift (from HARDCODED)
watchman.supportdir = bin/watchman (from HARDCODED)
  • w

    witty-crayon-22786

    06/05/2017, 9:19 PM
    i think the binary name is custom in there though.
  • w

    witty-crayon-22786

    06/05/2017, 9:19 PM
    (the directory content)
  • w

    witty-crayon-22786

    06/05/2017, 9:22 PM
    ...better yet, can dump that as json
  • b

    bright-apartment-76721

    06/05/2017, 9:36 PM
    yup that's what I did, I just figured it would be a more first-class notion
  • b

    bright-apartment-76721

    06/05/2017, 9:36 PM
    because my goal was to add a "I already have this so don't bother "downloading" from file://"
  • b

    bright-apartment-76721

    06/05/2017, 9:36 PM
    and generally try to get the pants-as-an-informal-package-manager stuff under control in my offline environment
  • b

    bright-apartment-76721

    06/05/2017, 9:53 PM
    to put it differently, it seems better for a subsystem to declare "I use three binaries, from bin/foo" and for the system to automatically add a supportdir argument that defaults to bin/foo, set up the download of the three binaries (which are then indexable/memoized like all the subsystems do manually right now). Instead of manually having everyone add --supportdir to each subsystem and then grepping the options to find binaries
  • b

    bright-apartment-76721

    06/05/2017, 9:53 PM
    assuming I can get it working 🙂
  • b

    bright-apartment-76721

    06/05/2017, 9:54 PM
    (and hoping that people are consistent in their naming of supportdir, etc.)
  • w

    witty-crayon-22786

    06/05/2017, 11:44 PM
    @enough-analyst-54434 : i haven't had time to dive into https://github.com/pantsbuild/pants/pull/4638 , but it seems like to be related to test caching / isolation (because multiple roots)
  • e

    enough-analyst-54434

    06/05/2017, 11:48 PM
    K, thanks for the heads-up
  • p

    purple-oil-45048

    06/06/2017, 5:11 AM
    @fast-megabyte-33579 I was thinking of publishing the 
    *.pex
    to our artifactory so that we can use it for the deployment later on
  • f

    fast-megabyte-33579

    06/06/2017, 12:53 PM
    I thought there was an option for 
    resolve
    that would say "you depend on these jars and these new versions are available" but I can't find it any more - am I looking in the wrong place?
  • e

    enough-analyst-54434

    06/06/2017, 3:19 PM
    @fast-megabyte-33579 its 
    outdated
    , an undocumented goal:
    Copy code
    ./pants goals --all
...
Undocumented goals:
  jar kythe outdated pyprep
  • f

    fast-megabyte-33579

    06/06/2017, 3:20 PM
    bingo, thanks @enough-analyst-54434
  • r

    rough-dog-96241

    06/06/2017, 3:58 PM
    Has anyone seen an issue where, in a loose plugins directory, register.py's get compiled to .pycs, register.py's change, and the .pycs go stale?:
  • w

    witty-crayon-22786

    06/06/2017, 4:20 PM
    @rough-dog-96241 : not really. you're not using the daemon though, are you?
  • r

    rough-dog-96241

    06/06/2017, 4:21 PM
    nope, excited about trying that at some point, though
  • r

    rough-dog-96241

    06/06/2017, 4:21 PM
    I blew away the .pyc and everything's fine. Just kind of crazy.
  • r

    rough-dog-96241

    06/06/2017, 4:21 PM
    ¯\_(ツ)_/¯
  • r

    rough-dog-96241

    06/06/2017, 4:22 PM
    Somehow, I guess the .pyc got touched before it got evaluated to be re-written.
  • w

    witty-crayon-22786

    06/06/2017, 4:24 PM
    that's... a thing on older pythons i think.
  • w

    witty-crayon-22786

    06/06/2017, 4:25 PM
    if Kris comes along he might confirm
  • r

    rough-dog-96241

    06/06/2017, 4:26 PM
    well, we are known to run older pythons on build boxen. (argh)
  • a

    able-finland-42099

    06/06/2017, 8:31 PM
    Howdy, has anyone here used the 
    alias()
    target to group together more than one target? The documentation describes the alias as
    Copy code
    alias: A target that gets replaced by its dependencies.
    dependencies = ...,	(default: [])
    description = ...,	(default: None)
    name = ...,	
    no_cache = ...,	(default: False)
    tags = ...,	(default: None)
    My reading of this is that I provide a list of targets in 
    dependencies
    so that I can run a goal against the alias and have it run on all the dependencies. However, this doesn't seem to be the case. When I run a goal pants complains that I must specify a 
    target
    parameter. Looking at the code, I see that the AliasTarget class takes the 
    target
    param and sets it as the only dependency. Am I not understanding the alias use case?
  • w

    witty-crayon-22786

    06/06/2017, 8:31 PM
    @able-finland-42099 : 
    alias(name='x', target='y')
    is for exactly one destination
  • w

    witty-crayon-22786

    06/06/2017, 8:32 PM
    target(name='x', dependencies=['y', 'z'])
    is for multiple destinations
  • a

    able-finland-42099

    06/06/2017, 8:36 PM
    @witty-crayon-22786 Ah, I see. As far as the dep graph goes, 
    target()
    will be at the top and my grouped destinations will all be considered dependencies right? That could affect some task behavior right?
  • w

    witty-crayon-22786

    06/06/2017, 8:49 PM
    @able-finland-42099 : the 
    target
    definition should not change the behaviour of the build any more than doing something like 
    ./pants test y z
    would
1...175317541755...2420Latest