Hey everyone, i'm in the process of evaluating pants for my company's python projects and i'm looking for advice on two last blockers before I can introduce the workflow to my team - what's the best channel to ask about these? I've tried reading the docs over/over and i can't get anything working the way i'd like.

You found it! Most things go in #C046T6T9U

Fantastic, so in our existing setup, we basically have what pants offers but i've just ductaped together a combination of makkefiles, bash scripts, poetry, and docker which sucks to maintain, especially if tools like pants are built to do this already. it does, however, work. currently all our projects are in their own repo setup with a cookiecutter and thsi produces scripts for every project that do things like, restore a database for dev, migrate/revision with alembic, (run black, isrot,etc which already work). That's nice about this is i have makefile at the top level of each project that abstracts that all away (make build, make lint, make fmt, make migrate ,etc) 1) what i'd like is ideally have this defined once in our (new pants) monorepo, and then i can run pants migrate {projectName}, etc. what's the best way to go about doing this? 2) something that i know my team will hate is having to type out full paths to each project. ideally you can say something like pants lint {projectName} rather than pants line src/python/project

For 2) there’s

[cli.alias]

On mobile now, can provide example and link to docs tomorrow if desired ;)

You mention

migrate

- are these django projects?

cli.alias looks good - docs would be very much appreciated and no not django migrate, we're using alembic (which is an sqlalchemy thing) but basically the same idea. I've seen the django example where they have a manage.py situation, which is fine, but i would rather just reuse the scripts we had if there's a nice way. I"ve seen the pex binary target or possibly making my own backend? but any advice here would be nice

We use Alembic and have

cli.alias

like

foo_database = “run path/to/migrations/wrapper.py”

which we use like

pants foo_database -- upgrade

. For your situation, that might be an option, although others might be: • continuing to use make as a command runner, but have it basically just invoke pants commands (preferably just temporarily, but would at least relieve the acute pain?) • setting up aliases for commands as discussed above, and project paths, eg I suspect an alias like

projectA = “src/python/projectA::”

would allow

pants lint projectA

to do the right thing (lint everything in that directory and it’s descendants) • Write a plug-in/backend, which is more of a commitment

@broad-processor-92400 what's inside the wrapper.py - is this a script that is copy pasted to each project?

I’m not at my computer right now, but it’s a call to a shared helper, eg:

from common import migration_wrapper
migration_wrapper.main(“projectA”)

so it would be like pants foo_database -- upgrade projectName