sorry for the late response stu - I was out. Will look now

@silly-king-27579 - I inherited this problem when our org named the OSS wing io.fsq. I “worked around” it by reversing the namespace for our python.

src/jvm/io/fsq/foo
src/python/fsqio/foo

I like this solution because it matches what happens with urls in general - the java convention is to reverse, so that becomes the special case. We also considered

src/python/fsq

but decided to go with the above

@fast-megabyte-33579 : sorry, what context are we talking about here? are these

python_binary

targets that you're building?

@gorgeous-alligator-94763 : flaky perhaps? kicked off again.

@limited-country-20626 yeah, I understood what was going on as soon as I wrote it out... rubber-duckie debugging 🙂

is anyone working on a python_protobuf_library, with grpc support? I've seen

java_protobuf_library

, but

git grep python_protobuf

does not return anything

at least not in

master

🙂

I read (in the #fsqio channel) that the webpack plugin was depcrecated and that the 1.3.x series of pants had native support. Is this accurate or did I get my wires crossed?

there is not native support for webpack, but there is native support for using npm and yarn

and folks use webpack that way.

I see. Thank you

hi. I upgraded to 1.3.0rc0 and started running into issues with parse_context.rel_path, both in my own code and in pants code.

there is a comment about only accessing ParseContext fields in call methods now, not init methods, but code like BuildFilePath still accesses it in init.

This has been leading to the value being None.

Maybe I should enter a bug to describe it better.

@straight-waiter-86090 : yes please

... i didn't know that

BuildFilePath

existed.

@straight-waiter-86090 : actually, yea... no need for a ticket.

i'll fix that.

sounds good.

there are some others. not sure if they’re affected too.

FilesetRelPathWrapper

,

JarDependencyParseContextWrapper

for example

anything that has test coverage should already have been updated. sigh.

will audit, thanks!

FilesetRelPathWrapper

in particular is only used in the

v1

engine, so it was safe here, but the

JarDependencyParseContextWrapper

was a legitimate issue.

@straight-waiter-86090 : thanks for the report... can credit you here if you'd like? https://github.com/pantsbuild/pants/pull/4583

@wide-energy-11069 : not sure why it doesn't explode, but:

register('--ignore-patterns', advanced=True, type=list, fromfile=True,
             default=['.*/', rel_distdir, 'bower_components/', 'node_modules/', '*.egg-info/'],
             removal_version='1.3.0.dev0', removal_hint='Use --build-ignore instead.',
             mutually_exclusive_group='build_ignore', help='See help for --build-ignore.')

...has been disabled since 1.3.0dev0, so should be good to remove it in 1.4.0dev0

sure

has anyone written pants plugins to run security checks? e.g. https://github.com/awslabs/git-secrets, https://github.com/dxa4481/truffleHog, https://github.com/albuch/sbt-dependency-check. o/w any pointers on how to write a plugin to call out to shell script? the last example is more involved has to check all the dep files

@mysterious-action-44812 Plugins can just run python, so can subprocess out to run things; not sure you actually need to though; git-secrets is a git hook, truffleHog you can use through python directly, and the last one (using the underlying dependency check) you could invoke as a jvm program.