Is there a straightforward way to package and appe...
# general
h
Is there a straightforward way to package and append a dev release specifier to the version of a package? I want to package a
python_distribution
and modify its
provides.python_artifact.version
to include a dev release:
wheel-1.2.3.whl
->
wheel-1.2.3.dev1.whl
but can’t see a way to do this with
__defaults__
and
vcs_version
plugin isn’t exactly what I want.
w
I've put this into a prelude (pants macro) file:
Copy code
def acme_version(value: str) -> str:
    """Define a version.

    This will include any pre-release suffix as applicable.
    """
    return value + env("PRE_RELEASE_SUFFIX")


def acme_lib(version: str, provides=None, **kwargs):
    python_distribution(
        provides=python_artifact(
            name=build_file_dir().name,
            version=acme_version(version),
            **(provides or {}),
        ),
        **kwargs,
    )
and in
.pants.bootstrap
Copy code
# Set some default values, unless provided..
export BRANCH=${BRANCH:-$(git rev-parse --abbrev-ref HEAD)}
export BUILD_NUMBER=${BUILD_NUMBER:-0}

# Setup release variant (stable / dev) based on branch.
if [ "${BRANCH}" == "master" ]; then
    PRE_RELEASE_SUFFIX=
else
    PRE_RELEASE_SUFFIX=".dev${BUILD_NUMBER}"
fi
export PRE_RELEASE_SUFFIX
h
That looks like what I need. Is there a way I could make sure .pants.bootstrap is only applied conditionally? In the same way that I’ve done with my CI pants config file:
PANTS_CONFIG_FILES=pants.ci.toml
c
Maybe there is a CI variable or something to put it behind. It’s a shell script so regular if-expressions etc are available.
h
I can see ‘dev.pants.bootstrap’ and ‘ci.pants.bootstrap’ variations being useful the same way ‘dev.env’ and ‘prod.env’ are a common pattern
c
You can pull those in as needed from your .pants.bootstrap, but only you know what to look for to identify a CI run..
h
This is what I have currently in
macros.py
, I’m decided to pass through the version from provides instead but I’m getting an error when trying to unpack and pass provides as kwargs using your example:
Copy code
# macros.py
def python_distribution2(provides=None, **kwargs):
    python_distribution(
        provides=python_artifact(
            name=build_file_dir().name,
            version=dev_version(provides.kwargs["version"]),
            **(provides or {}),
        ),
        **kwargs,
    )

MappingError: Failed to parse ./oxlibs/oxlibs/BUILD:
TypeError: pants.backend.python.macros.python_artifact.PythonArtifact() argument after ** must be a mapping, not PythonArtifact
Using
provides.kwargs
instead duplicates the name/version fields, is there a way to only provide the kwargs that aren’t overwritten?
I’ve got it working slightly differently now but I have another question. Is it possible to overwrite the default targets? Say if I wanted to overwrite
python_distribution
with my
python_distribution_custom
macro?
c
I think it is better to stick with using
python_distribution_custom
rather than replacing the original target with the custom one, as that could be surprising to folks looking up docs etc for the target if not realizing it has been customized.
h
Hey @curved-television-6568 I could do with some assistance on this, I have the below macro set up that enables adding a version suffix with an env var. The problem I’m having is that this also applies to all other python_distribution targets that are built at that time such as dependencies of the python_distribution(s) that I’m specifying to be built.
Copy code
def python_distribution_custom(provides=None, **kwargs):
    python_distribution(
        provides=python_artifact(
            **dict(provides.kwargs,
                name=build_file_dir().name,
                version=modify_version(provides.kwargs["version"])
            ) or {},
        ),
        **kwargs,
    )
Is there a nice way for me to only apply this modification on the targets that are being passed to
pants package <targets>
and not the first-party dependents of those targets?
c
Ah.. that's tricky to do from BUILD files alone. Maybe if you have dedicated env vars per target, if feasible?
h
AFAIU it’s not actually building the first-party dependency, but “building” the target to resolve all dependency requirements of the package <target>. Could this work internally if targets had context for why they were being initialised? Packaged for distribution vs. target compilation(?) for resolves? Alternatively, is there a more complex route I could go with this macro that would allow for processing the targets being explicitly passed properly? A plugin or something?
c
Well yes, a plugin would be able to know what targets are being requested and what the current goal is.
h
Is there a close example you know of that you could share as a jumping off point?