I don't think so. What's the use-case?

was wanting to a gradual migration away from using src/python and tests/python. though as I think about it I guess there’s not really that many places that would break if the switch was done atomically

you can move tests over to

src/

slowly, no? and then rename

src/

away atomically.

I’m not even trying to co-mingle tests and src right now, just moving src/python/my_org to ROOT/my_org and moving tests/python/my_org_test to ROOT/my_org_test

this issue asks if it's reasonable to have a different default option value depending on whether stdin is a tty, in this case the timeout for killing a hung pantsd-runner subprocess after ctrl-c https://github.com/pantsbuild/pants/issues/7514. looking for thoughts on whether this would be extremely surprising/spooky to anyone or if i'm missing another obvious solution, i expect it should be fine but wanted to check

Is there someone trying to get pantsbuild to work with kotlin?

i love scrolling through the pants open pull requests feed like it's the morning paper jsyk

Just a random question, what is the

CACHE_NAME

env var used for in

.travis.yml.mustache

? Can I override it if I want to create more shards? (sth like

CACHE_NAME=cronjob{{.}}.with_feature

)

So, we have a legacy task that extends bundle for use with our legacy Hadoop cluster. The task only exists to add a VERSION file to the bundle, that file just includes the git sha.

Is there a bundle-native way to include this in the deployjar?

I either have to rework that task or delete it - prefer the former

Zundel added something, but I'm not sure whether it is currently used

Potentially dumb question, but I'm trying to get the ./pants repl command to default to ipython. This is what I have in my pants.ini file, but it isn't going into ipython:

[repl.py]
ipython = True

When invoking something like

./pants repl --repl-py-ipython src/starsky_utils

it works perfectly! am I reading the docs on options & scopes wrong?

i think you'll want:

[repl.repl.py]
ipython = True

because adding options after a goal name is the same as prefixing them with that name -- so your command could have also been written as

./pants --repl-repl-py-ipython repl src/starsky_utils

. it is however strange that setting

--repl-py-ipython

without the deeper scope doesn't work, and it's not clear to me why we have a nested

[repl.repl.py]

scope at all

that........or we have an options parsing bug, hope not

Does pants project follow any Python style guide?

pylintrc.txt

is there a better way than

./pants --changed-since=X list | grep some/target

to check if a particular target has changed?

(a coworker recently ran into an issue where they were accidentally greping for a/b/:c instead of a/b:c)

there will be, when i get my act together and flesh out https://github.com/pantsbuild/pants/issues/7346, otherwise your options are

grep -P

, or i publish this hacky script i use sometimes that intersects lines of files

I've successfully migrated 2 repos to a pants monorepo. Tests all run! Now I want to make them fast and parallelized, like using pytest-xdist[1] to run them all in parallel. Whats the best way to get ./pants test to be able to use their pytest extension? Passing in

options="-n 10"

errors out w/ unrecognized arguments: -n [1] https://pypi.org/project/pytest-xdist/

Two things can improve pants project: 1-No import for individual function or classes directly from the modules. Instead, import the modules then access the function or class from the module. It will make namespacing better. I saw lot of code that say

from foo.bar import OrderedDict

, then another part of the project say

from twitter.foo.x import OrderedDict

. I feel it make it really hard to distinguish. 2-The second thing. Test are located outside of the source code directory. If I want to know a module has a unittest, I will need to open a separate directory outside of the project source code, and look for the unittests. Unittests are used as a document to understand how the module works. At Google, all of the unittests are located next to the module. If you open any directory. You will see something like this:

foo.py

and

foo_test.py

. Here at the company I work at we create a directory called

tests

and we store all the tests related to the modules in it. So, if I have

foo.py

in a directory, the test will be located in

tests/foo_test.py

in the same directory of

foo.py

.

@fresh-architect-74417 Re your #2: https://github.com/pantsbuild/pants/issues/7489

I feel the same as you about this

re #1 -- we're thinking of adding a lint for exactly that: https://github.com/pantsbuild/pants/issues/7106 (to avoid accidentally importing transitively). i wasn't sure how to write that lint yet but importing objects with

from...import

feels actually more consistent to me, and is a pattern we try to employ in the rust codebase as well, so it's quite consistent across the project and changing that would be a big step i think. it's definitely more injectable and easier to mock, i think, even if most python projects don't tend to use this style [citation needed, i'm not a pythonista yet].

@aloof-angle-91616 In my company, we don't use

from

at all. We import the full as an alias instead. That will prevent accidental imports for functions/classes/etc

yes, i believe however would be a pretty large style change for this codebase which might cause more confusion than it would fix. since pants plugin developers (probably?) use a similar style to the examples in the pants repo, making this style change i think might also be confusing for downstream users. we check for unused imports and the only times we've come across issues with aliasing we've been able to resolve them quickly.

This style guide is used at Google: https://github.com/google/styleguide/blob/gh-pages/pyguide.md We can fork it and change it to follow our needs. From a thread in #general

when you've contributed a few patches and gotten a feel for the codebase this conversation will be more fruitful i think

Hello all!