hey. any ideas how to you get the dependencies for a target? From the code it looks like this information is available at the target level, but retrieving a target depends on the build graph and I do not know how to get this information?

from pants.backend.python.targets.python_target import PythonTarget
from pants.build_graph.build_graph import BuildGraph
from pants.build_graph.address import Address,

# How to get dependencies?
address = Address(lib_path, lib_name)     
# target = graph??.get_target(address)
# target = PythonTarget(name=name, address=address, build_graph=build_graph???)
dependencies = target.dependencies()

cc @hundreds-father-404 can you answer this? thanks.

Hey Adrian, what Pants version are you using? Those are types from the old v1 engine and have been removed in Pants 2.0. With the Rules API, you get the

Dependencies

of a target like this: https://www.pantsbuild.org/v2.0/docs/rules-api-and-target-api

I am currently using latest stable version 1.30, but can switch to any version if needed

I'm wondering, are you looking at scm versioning just to figure out if any inputs to the dist have changed? Because Pants already has that invalidation logic, it knows exactly what inputs went into producing a dist, and we could possibly expose a fingerprint that represents that.

So I am using a versioning per library using git subtrees. My code is described here https://github.com/pantsbuild/pants/issues/10633#issuecomment-677889311 . What I want to achieve is a way to increment versions in my python libraries based on code changes. I do not want to manually increment the version in the BUILD file.

So I may trying to add a logic of dependencies inside the versioning function

Cool. The Rules API has a prebuilt utility to do this, find the “dependees” of any file. For example, run

./pants --changed-since=HEAD list

. From there, you can filter out any irrelevant dependees that don’t have a

setup_py

.

I chose git subtrees logic for versioning instead of maintaning a versioning file in the repo for multiple reasons: git is the single point of truth and from what @hundreds-father-404 told me doing file writes inside the versioning function would be dangerous because of how pants works.

Doing file writes is fine if you use the Rules API, which we’re going to end up needing for the functionality you want. It happens in a controlled manner that is safe and works properly with caching Are you wanting to commit to using

git subtree

, or that was more in response to what I had said, and you’d be fine using VERSION files that get checked in and are automatically managed?

How can I setup the rules API inside of my scm function? If not possible what are the alternatives to add this versioning function to the process of building a python library (setup-py goal)?

Yes, pardon the confusion. See https://www.pantsbuild.org/v2.0/docs/pants-1-vs-2 for an explanation of the difference, and its linked page “How to upgrade” tl;dr, you’re on Pants version 1.30, which supports both the legacy “v1 engine” and the new “v2 engine”. Pants 2.0.0a1 removes the legacy v1 engine

That sounds great. Thx

In the meantime, how is the PyInstaller thing going? Anything we can help with?

I am digging into pantsbuild GitHub code to understand how everything works. Also, internally I am looking to make our pyinstaler solution generic. You could help me with a couple of things: 1. What version should I look at? 1.30x branch or master? From what I've heard from you it sounds that there are major functionality changes on pants v2. Do I need to build the solution on v2? Can it be used in 1.30? 2. Is there a dev doc to help me get familiarized with the code? 3. Can you highlight some classes or a similar approach of implementing such a use case? This would help me better understand how everything fits together and where the pyinstaler code must reside

1.

master

branch. We made lots of changes to the Rules API between 1.30 and 2.0 for it to be more stable 2 and 3. Yep 🙂 See https://www.pantsbuild.org/v2.0/docs/plugins-overview, and in particular https://www.pantsbuild.org/v2.0/docs/plugins-binary-goal, which includes a link to an example repo Generally, reading those docs will likely go further than looking at the source code without guidance. On the

Create binaries

guide, step #1 of creating a binary target type is a good one here. You’ll want to create a new

pyinstaller_binary

target type.

Thx. Will look at it tomorrow