is your goal to make changes to the

maskrcnn-benchmark

source code, and test those out? or just to consume the released version of the library in your python code?

you can also feel free to make an issue at https://github.com/pantsbuild/pants/issues/new describing what you'd like to do and tagging @aloof-angle-91616

i've been waiting for an excuse to jump back into that code :) but i hope the native backend will be able to do what you want already

also feel free to message me on slack anytime about this

sure thanks @aloof-angle-91616 🙂

looked a bit in the already created issues, maybe it's a duplicate of this one ? https://github.com/pantsbuild/pants/issues/4740

but yes, my goal is to be able to consume a

maskrcnn-benchmark

source code (and define the version with commit/tag/ branch)

I'm developing a pants plugin. Our source code root directory is called

pants

. Does pantsbuild support 3rd party package aliasing? So instead of doing this

import pants.goal.task_registrar

I want to do that

import pant_alias.goal.task_registrar

Hi all, I’m repeating myself from the pants-devel mailing list and the commit message, but I thought it would be better to over-advertise this rather than under-advertise it: The PR that formats our python code with Black (https://github.com/pantsbuild/pants/pull/8391) was merged this morning (London time). It means that if you have an ongoing branch that predates that PR, you will need to do a little dance to avoid having to manually resolve formatting related conflicts next time you pull master. Here are some steps you may follow that should make the process automatic:

# Checkout your feature branch
git checkout feature_branch

# The pre-commit check can be a little annoying when doing rebases (can't pass --no-verify).
# Let's manually disable it for the time of our rebases
mv ./.git/hooks/pre-commit ./.git/hooks/pre-commit.backup

# Manually handle any (genuine) conflict pre_black
git rebase black-formatting^

# Automatically format the code in each commit of your feature branch
git rebase --interactive --exec './pants --owner-of="`git show --name-only --pretty=\"\" HEAD`" fmt-v2 && git add `git show --name-only --pretty="" HEAD` && git commit --amend --no-edit && git stash' black-formatting^

# Rebase your formatted code on top of the black commit.
# Because of the previous step, and because the black commit only formats files,
# This should not cause any conflict.
# (Caveat: if you touched the isort config or one of the tests that were formatting dependent,
# you may have a small amount of conflicts to handle)
git rebase --interactive --strategy-option=theirs --exec './pants --changed-parent="HEAD^" fmt-v2 && git add `git show --name-only --pretty="" HEAD` && git commit --amend --no-edit' black-formatting

# Handle any conflict since black (only genuine conflicts. formatting won't be part of it)
git rebase master

# Don't forget to re-enable the pre-commit hook
mv ./.git/hooks/pre-commit.backup ./.git/hooks/pre-commit

# All done. When you're ready, you may update your PR.
git push -f your_remote feature_branch

If you have any difficulty with the above steps, or are unsure about anything; feel free to DM me and I will help you through it 😄 Thanks everyone for the discussions, reviews and comments that made this possible 🙂

Do subsystems need some kind of registration? If I run

./pants -ldebug --compile-rsc-worker-count=8 --process-execution-local-parallelism=8 --compile-rsc-execution-strategy=hermetic --no-compile-rsc-incremental --compile-rsc-workflow=rsc-and-zinc compile --cache-ignore examples/src/scala/org/pantsbuild/example/hello::

I get told:

No such options scope: rsc

when

RscCompile

tries to access

Rsc.global_instance()

Aah think I found it - not sure why this was working before…

Hey, so re the black change. Did "we" decide to switch from 2 space indents to 4 spaces? That seems like something that should have been socialized and discussed. cc @fancy-motherboard-24956 @witty-crayon-22786

It's not configurable in black. And yea, that was highlighted in the initial doc

I naturally assumed we would be enforcing our existing formatting, not inventing new standards.

That is not configurable? Amazing

Yes, was brought up here: https://pantsbuild.slack.com/archives/C046T6T9U/p1569413859055800

Ah well

are we saying that our tooling is stopping us from using 2-space indents?

Apparently that is what we are saying.

it sounds like we might want to look at improving our tooling

For future reference: This is the kind of thing pants-devel@ is for. We can't assume that a discussion on slack counts as "informing the community".

Otherwise everyone has to read all slack history all the time.

in the interest of not losing work i'll look at making black support 2 spaces, forking it now

Read their readme: I would be really surprised if that gained traction for them

we are not the psf!

Someone already forked this! I’m on phone but this was a year or two ago. Look at their closed issues, @wide-energy-11069 had opened a ticket about adding support for two spaces. Last time I checked, the fork was outdated

Not sure where you think you are “loosing work”?

so that we don't have to revert the changes

I wouldn't recommend reverting this, over an arbitrary formatting decision that some people (myself included) disagree with. I can make a weak argument for why 2 spaces is better than 4 spaces, but it is too weak to drive any decisions.

i'm pretty sure the change to black is a one-line change