maybe what I would be happier with is to glue together jvm-platforms and jvm-distributions into the same subsystem for configuration purposes.

That sounds reasonablish

But now I see that this might be awkward when declaring dependencies, e.g. “Why do you need to add a dependency on the JvmPlatform subsystem when we are using the Distribution object?"

Even if I were to agree with the multiple subsystems, having —jvm as a prefix and the entire name of a subsystem seems to be confusing… I’m not sure what to do about that.

I don't understand why you;d need to do that

If you need a Distribtuion you depend on its factory

and ask the factory for 1

that's what Garrett has unless I misunderstand

Here’s what I mean:

jvm advanced options:
 
--jvm-exclude-target-regexp=<regexp> (--jvm-exclude-target-regexp=<regexp>) ... (default: [':aux-','service/container/wire-tests'])
    Exclude targets that match these regexes. Useful with ::, to ignore broken
    BUILD files.
--jvm-cache-key-gen-version=<str> (default: 200)
    The cache key generation. Bump this to invalidate every artifact for a
    scope.
--jvm-max-subprocess-args=<int> (default: 100)
    Used to limit the number of arguments passed to some subprocesses by
    breakingthe command up into multiple invocations
--jvm-debug-port=<int> (default: 5005)
    The JVM will listen for a debugger on this port.
--jvm-debug-args="['str1','str2',...]" (default: ['-Xdebug','-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address={debug_port}'])
    The JVM remote-debugging arguments. {debug_port} will be replaced with the
    value of the --debug-port option.
--jvm-jdk-paths="{ 'key1': val1,'key2': val2,...}" (default: None)
    Map of os names to lists of paths to jdks. These paths will be searched
    before everything else (before the JDK_HOME, JAVA_HOME, PATH environment
    variables) when locating a jvm to use. The same OS can be specified via
    several different aliases, according to this map: darwin: [darwin, mac, mac
    os x, macos, macosx], linux: [linux, linux2]

jvm-platform recursive options:
 
--jvm-platform-l=<str>, --jvm-platform-level=<str> (default: info)
    Set the logging level.
--[no-]jvm-platform-colors (default: True)
    Set whether log messages are displayed in color.

To configure —jvm-debug-args in pants.ini, you put it in

[jvm]

, but to configure —jvm-platform-l` you put it in

[jvm-platform]

OK - seperate issue?

@enough-analyst-54434: one annoyance with partitioning subsystems currently is that in order to have more-fine-grained dependencies, you pollute the config namespace

Table it and solve the scope vs dash vs prefix thing generally

in a different RB?

Its a separate issue I suppose, but related to our proliferation of subsystems.

I guess so, but this stuff is all advanced

I just have never been sensistive to it being slightly ibscure

Predictable. You know every line of code in the project.

!

If you have to configure any of it thats a bit strange to start

(that is in jest by the way)

Nono - I mean if we do our job right with subsystems, even if they are confusing to configure that should ~never show up

not in flags - they're advanced, nor in needs of users, because the defaults are good

hehe

Well, I guess I’m considering ‘users’ new adopters of and champions pants too.

I’m very happy with the new options system exposing all of these settings through help (I think subsystems haven’t made it into the online docs yet), so life is better than it was 6 months ago.

And your output above is - with minimal training - easy to pants.ini

Look at the header for the [] part

subtract that part from the flag prefix

+1 for "glue together jvm-platforms and jvm-distributions into the same subsystem for configuration purposes"