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

    clever-ambulance-21321

    03/18/2016, 8:54 PM
    ok
  • r

    rough-minister-58256

    03/18/2016, 8:55 PM
    you can also 
    unzip -c the.pex -C PEX-INFO
    and verify the zip_safe flag is correctly set in the pex you’re running
  • c

    clever-ambulance-21321

    03/18/2016, 8:55 PM
    "zip_safe": false,
  • c

    clever-ambulance-21321

    03/18/2016, 8:55 PM
    yah it's in that output
  • c

    clever-ambulance-21321

    03/18/2016, 8:56 PM
    interesting, I do see everything in ~/.pex/code/<some long string>
  • j

    jolly-chef-92794

    03/18/2016, 8:56 PM
    @witty-crayon-22786: for the project I was talking about earlier, I should mention that it’s literally the only project in the repo using the versions of hadoop-related artifacts that it does
  • j

    jolly-chef-92794

    03/18/2016, 8:57 PM
    It’s not a global thing that would be reusable for the rest of our repository, so it really would just be extra boilerplate in this case
  • j

    jolly-chef-92794

    03/18/2016, 8:57 PM
    Which is why I think a context-aware build file object factory thingy would be nice
  • c

    clever-ambulance-21321

    03/18/2016, 8:59 PM
    which leads to the next obvious question - what makes the flask app look for the resources in ~/.pex/ instead of ~/theapp.pex/
  • r

    rough-minister-58256

    03/18/2016, 9:01 PM
  • r

    rough-minister-58256

    03/18/2016, 9:03 PM
    ah I think I see the issue - since you’re in the 
    __main__
    namespace, flask defaults to 
    os.getcwd()
    as the root path
  • r

    rough-minister-58256

    03/18/2016, 9:03 PM
    we almost always put all of our code in modules and use the 
    __main__
    path to import and exec an entrypoint
  • c

    clever-ambulance-21321

    03/18/2016, 9:03 PM
    that makes sense to me
  • r

    rough-minister-58256

    03/18/2016, 9:04 PM
    so if its loaded from a module, flask looks at 
    module.__file__
    which should ‘just work’ in the 
    zip_safe=False
    context
  • r

    rough-minister-58256

    03/18/2016, 9:04 PM
    btw, wanna take this convo to #C087V4P1T so we don’t clutter up #C046T6T9U?
  • c

    clever-ambulance-21321

    03/18/2016, 9:04 PM
    sure
  • j

    jolly-chef-92794

    03/18/2016, 9:04 PM
    I would also like @happy-kitchen-89482’s opinion on the transitivity issue. IIRC he had some strong opinions on how that should or shouldn’t work
  • a

    ancient-stone-50795

    03/18/2016, 9:06 PM
    Can I get a 🚢 -it on https://rbcommons.com/s/twitter/r/3585/ ? It passes locally, I'll merge it when travis-ci goes green
  • m

    mammoth-pharmacist-54215

    03/18/2016, 9:07 PM
    🚢
  • j

    jolly-chef-92794

    03/18/2016, 9:22 PM
    Wait, so if a 
    java_library
    has 
    scope=provided
    , and then you change it to 
    scope=runtime
    , its fingerprint will change and it’ll have to be recompiled? Even though nothing about it changed?
  • j

    jolly-chef-92794

    03/18/2016, 9:23 PM
    You have to change the fingerprint so the downstream dependencies change. I was handling that before by including the 
    scoped
    dependencies in a target’s fingerprint. But if the scopes are on the targets themselves, that doesn’t quite work
  • a

    ancient-stone-50795

    03/18/2016, 9:24 PM
  • a

    ancient-stone-50795

    03/18/2016, 9:26 PM
    I am waiting on another PR to finish up CI before running this release RB through travis. I will probably have to run the release itself late tonight or tomorrow morning if the release PR looks good.
  • a

    ancient-stone-50795

    03/18/2016, 9:38 PM
    @witty-crayon-22786: if we move scope to target, doesn't that make for 'surprising' behavior for targets that depend on it? Everyone expects that dependencies are transitive and available at runtime. Tagging the dep in the dependencies or scoped_dependencies list makes it clear that there is something very different going on with this target. We may not be able to solve this one way or another to each other's satisfaction. I'm open do allowing it to happen 'both' ways if you think it will be less configuration to mark a target, but i'm not so sure its generally preferrable.
  • w

    witty-crayon-22786

    03/18/2016, 9:43 PM
    @jolly-chef-92794: the set of deps that are marked compile/test/deploy is what would influence the fingerprint... but only for certain tasks
  • w

    witty-crayon-22786

    03/18/2016, 9:44 PM
    so 
    bundle
    would not include compile deps in its fingerprint?
  • w

    witty-crayon-22786

    03/18/2016, 9:45 PM
    @ancient-stone-50795: the transitive thing isn't true in the case of provided either... i don't think that's actually a difference
  • a

    ancient-stone-50795

    03/18/2016, 9:45 PM
    So you are saying leave the 'scope' field out of the target fingerprint
  • w

    witty-crayon-22786

    03/18/2016, 9:46 PM
    yes, i think so. only tasks would care about scope (as defined there...). this is again assuming a difference between scopes and transitivity rules.
  • w

    witty-crayon-22786

    03/18/2016, 9:47 PM
    i don't think we need multiple ways to do this... i'm just trying to encourage discussion that will help us find something that fits well with the pants model now, and in the new engine
1...107110721073...2420Latest