there are lots of errors in my nexus logs 😮

but I can log in as that user

I must have missed a permission

good catch, thanks

huh, “Unable to authenticate” as admin even

weird

I can make it “fail fast” by twiddling my

realm

so I’m guessing that’s correct now

yeah, that hang was very frustrating - might be nice to have a timeout but could be tricky because we want to allow time for the jars to upload in a legitimate publish.

I’m looking into implementing

provided_dependencies

It looks like I need to make sure they make it into

self.context.targets()

Which I have implemented as a special case locally

Except that we don’t want them for runtime/test/binary etc

Not sure whether it would be best to add a

with_provided=...

or

scope=…

kwarg to

targets()

, or if I should wrap targets 😕

I’m trying to also think a bit forward, since it seems likely that we will want more “scoped” kinds of dependencies like

runtime

or

codegen

or

test

maybe in the future

rargh

I had put

password=

in my

<credentials>

block when it should have been

passwd

it’s failing for a new reason now, but getting there

and now it all works

thanks Mateo - appreciate the pointers simple smile

yes! happy to help mike

@jolly-chef-92794: I'm not familiar enough with the details to have a strong opinion here, but it sounds like what you're describing should be living in a product pipeline, and not the graph proper

@bored-art-40741: I’m not sure how that would work. To summarize, we need provided dependencies which are only available before compile-time, and behave intransitively with respect to the classpath. However, despite being intransitive to the classpath, they (and their transitive dependencies) still need to be properly prepared before their dependees (prepared = compiled, resolved, generated, what-have-you). We were discussing having these included via a

provided_dependencies

parameter. I’m beginning to think it may be preferable to use syntax that looks more like:

target(
  scoped_dependencies=[
    scoped(‘provided’, ‘path/to/target:spec’),
    scoped(‘provided’, ‘path/to/target:spec’),
    scoped(‘provided’, ‘path/to/target:spec’),
  ],
)

Which could also support things like “runtime” dependencies without being ad-hoc. I don’t want to add slightly different versions of all existing build graph-related methods, (eg, closure_with_provided), and I don’t want to dramatically upheave the build graph API by adding kwargs like

with_provided=True

to all the method parameters. I think I will instead inject the scoped dependencies as normal dependencies, but filter them after the fact as needed in the tasks that care about them.

I’ll just put together a patch so we can get a more concrete picture of what’s going on

Hey folks. Is there a way to make pex import packages from system wide paths as well?

It excludes

/usr/lib/python2.7/site-packages

and

/usr/lib64/python2.7/site-packages

from the search paths

However, after importing some files, I see it adds

/usr/lib/python2.7/site-packages

to

sys.path

but not

/usr/lib64/python2.7/site-packages

if you’re using

pex

the tool, there’s this option:

@rough-minister-58256: I tried using

--inherit-path

but it didn't change anything 😕

I removed all cached dirs before building the pex file again