set version in python_artifact via vcs_version

[da-tubi]

Is your feature request related to a problem? Please describe.
I'm using pants 2.13.0rc1 for vcs_version. But I failed to set version in python_artifact by vcs_version.

Describe the solution you'd like
Make python_artifact work with vcs_version in a easy way.

Describe alternatives you've considered
I consider to hard-code the version part of python_artifact or use environment variable.

Additional context
python_artifact/vcs_version must work well with monorepo.

Currently, we use regex in vcs_version for detecting the tag of subprojects.

[Eric-Arellano]

Hi there! Could you please share more about how this is not working? Are there error messages?

Could you share your repository with us? Or create a simple repository to reproduce the issue?

[da-tubi]

I commented on the doc pull request #16092

Hi @benjyw , we are trying to setup a python monorepo. We need to make it work for publishing. Here is our publish process:

1. User: trigger the deployment CI
2. CI: run tests/lint and package
3. CI: upload the package to PyPI/Jfrog/...

During package, we need to specify the version in python_artifact. Using setup tools, Here is how I generate the version:
https://github.com/da-tubi/setup-py-best-practice/blob/2d8ae25e21e0af665fa87c5c11a2c973913f90bd/setup.py#L15-L16

But pants does not support the same setting. I have to give a value to version of python_artifact.

[benjyw]

If you have a handwritten setup.py (rather than letting Pants generate one for you) then you can use vcs_version to generate a source file that sets a version variable and then import that in setup.py.

See for example:

https://github.com/benjyw/black/blob/pantsify3/src/BUILD#L1
https://github.com/benjyw/black/blob/pantsify3/setup.py#L75

[da-tubi]

Thanks for providing the solution. Hope that there is a solution to use generated setup.py.

[da-tubi]

I think if pants find that use_scm_version=True is set, the following code snippet should be generated (not a ideal solution but there should be a solution):

if os.environ.get("RUNNING_IN_PANTS") == "1":
    from _black_version import version as __version__

[da-tubi]

Well using handwritten setup.py, we must hard code the requirements in setup.py. If I have to hard code setup.py, I'd rather use pants for developing and setup.py for publishing.

[benjyw]

I think having the generated setup.py use a vcs_version if available is a good idea!

[da-tubi]

I read about #12797

It seems for pants 2.12, there is no easy way to publish a python package with version computed from git tags.

I hope either #12797 or this issue could be resolved for pants 2.13.

For now, to complete the task, I have to learn about the internal of pants and try to write a plugin like:
https://github.com/pantsbuild/pants/tree/release_2.12.0/pants-plugins/internal_plugins/releases

[levous]

I just wanted to upvote this as it would be quite useful! If I am successful in creating a plugin, I'll be sure to open source that in the mean time. That's a little ways down my backlog, however, so it'll be a minute before I'm ready to tackle it

[IsmaelMartinez]

Hi @levous , did you get any far on that? I am sort of trying to solve the same problem (whoever in a slightly different way, asking the user for the version to bump)

[benjyw]

@IsmaelMartinez Are you referring to #18179?

[IsmaelMartinez]

Yes, slowly getting there. I am writing a goal/task that, hopefully, will run the poetry version command.

[AlirezaRoshanzamir]

I read about #12797

It seems for pants 2.12, there is no easy way to publish a python package with version computed from git tags.

I hope either #12797 or this issue could be resolved for pants 2.13.

For now, to complete the task, I have to learn about the internal of pants and try to write a plugin like: https://github.com/pantsbuild/pants/tree/release_2.12.0/pants-plugins/internal_plugins/releases

We have implemented this idea using Pants 2.16. However, it is not a good approach as it results in the entire cache being invalidated whenever the environment variable changes. This is because the changes to the BUILD file have a significant impact on caching. As a result, each run of the CI takes significantly more time. In fact, we employed setuptools-scm to populate the designated environment variable. However, since the version changes after each commit, the entire cache becomes obsolete.