Actually we can get a repro

(We think)

sounds like Nick will be able to take a look

But it's internal only, so we'll have to debug via clever logging

would be great to have a repro.

Not sure if people have seen this or not but I figured our github owners may be interested: https://github.com/blog/2064-new-organization-permissions-now-available

@witty-crayon-22786 @fancy-queen-20734 Worth noting that this issue appears to get triggered after a compile error where there's still a lot of graph left to attempt compiling

Yeah

I think it’s a exponential substitution problem

-.txt

Yup we just came to the same conclusion

Okay, so is Mateo's check the proper solution?

I’m working on one with tests

but qualitatively the same

sweet, thanks Nick.

no problem. Thanks for finding the bug

@limited-country-20626: https://rbcommons.com/s/twitter/r/2910/

@fancy-queen-20734: in buck, any directories names 'src' or 'test' are source roots automatically

(er, it's configurable, but)

even if they are nested?

@fancy-queen-20734: first one wins, one presumes (was what i suggested on the mailing list).

that makes sense

Looking into a resolve error we’re getting internally; traces back to:

Dependency = namedtuple('DependencyAttributes', ['org', 'name', 'rev', 'mutable', 'force',
                                                     'transitive'])
    global_dep_attributes = set(Dependency(org=<http://jar.org|jar.org>,
                                           name=jar.name,
                                           rev=jar.rev,
                                           mutable=jar.mutable,
                                           force=jar.force,
                                           transitive=jar.transitive)
                                for jar in jars)
    if len(global_dep_attributes) != 1:
      # TODO(John Sirois): Need to provide information about where these came from - could be
      # far-flung JarLibrary targets.  The jars here were collected from targets via
      # `calculate_classpath` above and so merging of the 2 could provide the context needed.
      # See: <https://github.com/pantsbuild/pants/issues/2239>
      conflicting_dependencies = sorted(str(g) for g in global_dep_attributes)
      raise cls.IvyResolveConflictingDepsError('Found conflicting dependencies:\n\t{}'
                                               .format('\n\t'.join(conflicting_dependencies)))
    jar_attributes = global_dep_attributes.pop()

Is having two jar_dependencies with different the same parameters as those above, but different

classifier

and value for

force

, not allowed?

@witty-crayon-22786: We have a compiler plugin that is raising

[Errno 7] Argument list too long

during junit. Is there any historical reason we don’t run junit in a nailgun?

@limited-country-20626: the various classpaths in use would cause pollution

so you wouldn't actually be able to use it for multiple instances

@limited-country-20626: @full-kilobyte-93429 is actually working on a fix for that one though

Nice

I have two questions

(but yea, in theory we could natively support a "one time use nailgun" situation)