pantsbuild / example-django

An example repo to demonstrate Django support in Pants

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

pants tailor command generating BUILD files without dependencies

sandeep2357 opened this issue · comments

First of all, Thanks for the repo and code structure. I intend to use this structure along with pants and docker for an ongoing project but facing issue while generating BUILD files.

I did a checkout of this repo and deleted BUILD files in helloworld/person and helloworld/service/admin/. When i try to run the pants tailor :: command now, the generated BUILD files are missing the dependencies.

The initial checkout BUILD file in helloworld/person looked like:

python_sources(
    dependencies=[
        "helloworld/person/migrations",
    ]
)

python_tests(
    name="tests",
    dependencies=[
        "helloworld",  # For settings.py.
    ],
)

python_test_utils(
    name="test_utils",
)

Whereas after deleting and running pants tailor :: command, the BUILD file changed to:

python_sources()

python_test_utils(
    name="test_utils",
)

python_tests(
    name="tests",
)

my pants.toml looks like:

[GLOBAL]
pants_version = "2.15.0"

backend_packages.add = [
  'pants.backend.python',
  'pants.backend.python.lint.docformatter',
  'pants.backend.python.lint.black',
  'pants.backend.python.lint.flake8',
  'pants.backend.python.lint.isort',
  'pants.backend.python.typecheck.mypy',
  'pants.backend.docker'
]

[source]
# The Python source root is the repo root. See https://www.pantsbuild.org/docs/source-roots.
root_patterns = ["/"]

[python]
# The default interpreter compatibility for code in this repo. Individual targets can override
#  this with the `compatibility` field. See
#  https://www.pantsbuild.org/docs/python-interpreter-compatibility.
interpreter_constraints = [">=3.11"]
# Use a lockfile. See https://www.pantsbuild.org/docs/python-third-party-dependencies.
enable_resolves = true
resolves = { python-default = "lockfiles/python-default.lock" }

[python-bootstrap]
# We search for interpreters on both on the $PATH and in the `$(pyenv root)/versions` folder.
# Note the gotcha that the order of entries does not matter in this option, as Pants will consider
# all interpreters it finds and select a compatible one.
# So, if you're using macOS, you may want to leave off the <PATH> entry to avoid using the
# problematic system Pythons. See
# https://www.pantsbuild.org/docs/python-interpreter-compatibility#changing-the-interpreter-search-path.
search_path = ["<PATH>", "<PYENV>"]

[python-infer]
# Infer dependencies from strings that look like module/class names, such as are often
# found in settings.py, where dependencies are enumerated as strings and not directly imported.
string_imports = true

[pytest]
lockfile = "lockfiles/pytest.lock"
version = "pytest>=7.3.1"
extra_requirements.add = [
  "pytest-django>=4,<5",
]

execution_slot_var = "PANTS_EXECUTION_SLOT"

[mypy]
lockfile = "lockfiles/mypy.lock"
version = "mypy==1.3.0"
interpreter_constraints = [">=3.11"]
extra_requirements.add = [
  # This is a mypy plugin, as well as a type stubs repository. So it must be mentioned
  # here as well as in requirements.txt.
  "django-stubs==4.2.0"
]

[flake8]
args=[
  "--max-line-length=120"
]

Do we have to write the dependencies ourselves if we want to maintain this monorepo structure for Django project? or am i missing something that supports autogeneration of BUILD files with dependencies?

Pants will infer most dependencies, only when that fails will you need to provide explicit dependencies, in your BUILD files, that will be used in addition to those inferred by Pants. pants tailor will never provide explicit dependencies for you (as if it could, those wouldn't have to be in the BUILD file either)

Yep - these are examples of explicit dependencies that are necessary because, unlike most dependencies, they can't be inferred automatically. Django has a lot of magic dependencies that rely on naming conventions or configuration. We're slowly adding those as custom dependency inference logic, but for now these must still be explicit.

So this is working as intended.

Closing as answered, but feel free to reopen if you think this is not resolved.