Don't parse stub file if interpreter is explicitly provided

[dflems]

It seems like --stub_file is only parsed to derive which interpreter is being used. Correct me if I'm wrong, but it seems like passing in --interpreter should short-circuit parsing that file. Seems like this will allow for using in-workspace py_runtime definitions as long as the interpreter is specified explicitly in the parfile() rule.

I might be missing some important context though.

[oxidase]

I had the same issue with non-system Python runtimes as parsing stubs before checking args.interpreter exits with an exception. I'll dismiss my PR #129 as this PR also add interpreter to the attributes list that is better than my workaround compiler_args = ["--interpreter", "/usr/bin/python3"],

@brandjon please could you review the fix.

[dflems]

closing and reopening to kickstart CI (which didn't seem to pick up my last commit)

[dflems]

@brandjon 👋 does anyone pay attention to this repo? 😢

[dmadisetti]

Note parse_stub also validates interpreter. Really it should be broken into parse_interpreter and validate_interpreter
then this would be:

interpreter = args.interpreter or parse_interpreter(args.stub_file)
validate_interperter(interpreter)

or something

[thundergolfer]

Seems like this will allow for using in-workspace py_runtime definitions as long as the interpreter is specified explicitly in the parfile() rule.

If you have an in-workspace interpreter at label @python3//:bin/python3 won't passing this as interpreter value result in a .par with a shebang like:

#!@python3//:bin/python3

How does the in-workspace interpreter label get translated into an absolute filepath?

[dflems]

@thundergolfer Ah that's true... On my end, I'm setting interpreter to /usr/bin/env python3 as we have some par_binarys that we export as internal tools